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SUMMARY 


Applications  of  the  GO  Methodology 

The  GO  methodology  has  been  available  since  1967.  It  was  originally 
developed  under  U.S.  Army  contracts  to  analyze  the  safety  and  reliability  of 
nuclear  weapons  and  missile  systems.  Using  the  GO  methodology  comprehensive 
safety  and  reliability  analyses  of  the  SPRINT,  SPARTAN,  NIKE  HERCULES,  HONEST 
JOHN,  LANCE,  PERSHING  la,  MADM,  M454,  M422,  and  M753  Army  nuclear  weapon 
systems  have  been  performed.  Similar  studies  have  been  performed  on  the 
POLARIS,  POSEIDON  and  TRIDENT  weapon  systems  for  the  Navy. 

In  the  late  70*  s,  GO  capabilities  were  expanded  under  EPRI  and  utility 
sponsorship  to  analyze  the  safety  and  availability  of  conventional  and  nuclear 
power  plants.  The  Kaman  Sciences  Corporation  (KSC)  team  which  developed  the 
GO  methodology  has  applied  it  to  analyze  the  Three-Mile  Island  Unit  2  SCRAM 
System,  the  Fort  St.  Vrain  SCRAM  System,  the  Dresden  2  Emergency  Diesel 
Generator  System,  the  Utah  Power  and  Light  Huntington  2  plant,  the  Sequoyah 
and  Belief onte  Auxiliary  Feedwater  Systems,  etc. 

KSC  also  demonstrated  the  GO  capability  to  model  and  analyze  an  entire 
nuclear  plant  -  the  TVA  Sequoyah  1.1  MWe  -  integrating  the  combined  effects  of 
approximately  60  systems  and  10,000  components  to  assess  plant  availability 
and  probabilistic  risks.  The  direct  accommodation  of  system  interactions  in 
one  integrated  model  was  one  significant  feature  of  this  study.  This 
capability  permits  the  identification  of  common  mode  faults  from  electrical, 
cooling  water  and  instrument  air  systems  which  may  affect  many  systems 
simultaneously . 

Application  of  the  GO  methodology  involves  five  steps:  (1)  gaining  a 
thorough  understanding  of  the  operation  of  the  system  to  be  modeled;  (2) 
defining  system  success  and  failure  states;  (3)  representing  physical 
components  and  logical  operations  with  GO  symbols;  (4)  interrelating  the  GO 
symbols  representing  physical  components  and  logical  operations  into  a  GO 
model  representing  the  engineering  functions  of  a  component /subsystem/system; 
and  (5)  executing  the  GO  computer  codes  to  quantify  system  performance  using 
the  system  GO  model.  The  methodology  is  capable  of  (1)  evaluating  system 
reliability/availability ,  (2)  identifying  system  fault  combinations,  (3) 
constructing  confidence  bounds  on  the  numerical  results,  and  (4)  ranking 
the  impact  of  constituent  elements  on  system  performance. 

Significant  Features  of  GO 

The  GO  methodology  possesses  some  significant  features  which 
differentiate  it  from  other  probabilistic  system  assessment  techniques.  Some 
of  these  modeling  characteristics  are  summarized  below: 
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(1)  GO  models,  which  are  composed  of  a  collection  of  operator 
symbols,  are  usually  developed  by  following  normal  process 
flow.  The  models  are  constructed  from  engineering 
blueprints  and  flow  diagrams  by  using  representative  GO 
symbols  for  physical  equipment  (valves,  motors,  pumps, 
etc.).  The  inputs  to,  and  the  outputs  from,  these 
elements  are  then  linked  together  to  form  a  GO  model.  The 
similarity  between  a  GO  model  and  its  corresponding 
engineering  drawing  makes  it  easy  to  validate  and 
interpret  the  model. 

(2)  GO  methodology  models  system  functions  and  operational 
logic.  Thus,  a  GO  model  contains  all  possible  system 
operational  states  of  the  constituent  elements.  The 
effects  of  system  design  enhancement,  procedural 
alterations,  etc. ,  on  the  various  operational  states  can 
be  evaluated. 

(3)  Alterations  and  updates  to  a  GO  model  are  readily 
accomplished.  Adding  or  deleting  components  or  altering 
the  logical  combinations  of  equipment  can  be  accommodated 
without  extensive  alterations  to  the  basic  model 
structure  of  the  computer  input  information.  Changes  to 
system  boundary  conditions  can  be  easily  accommodated  by 
changing  the  data  input  rather  than  by  changing  the  model 
itself.  The  block  modeling  feature  using  supertypes  also 
enhances  the  ease  with  which  model  alterations  can  be 
effected. 

(4)  The  identification  of  fault  sets  is  a  powerful  technique 

to  identify  various  equipment  failure  combinations  which 
preclude  successful  operation.  In  GO  terminology  the 
term  "fault  set"  is  used  as  being  more  general  than  cut 
set  because  GO  models  often  incorporate  more  than  just 
two  operational  modes,  e.g.,  success,  failure,  and 
premature.  Having  developed  a  GO  model,  the  fault  sets 
for  any  operational  state  of  a  system  can  be 

automatically  generated. 

(5)  The  GO  computer  codes  utilize  a  system  GO  model  and  the 

definitions  of  GO  symbols  to  quantify  system  performance. 
The  calculating  algorithms  in  the  computer  codes  employ  a 
truncation  procedure  whereby  events  of  least 

significance,  as  measured  by  their  probabilities  of 
occurrence,  are  discarded.  The  truncation  procedure 
enhances  the  computational  efficiency  of  the  methodology. 
The  error  introduced  by  truncation  is  known  and  can  be 
controlled. 
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Additional  characteristics  about  the  GO  methodology  which  experience  has 
shown  to  be  significant  are  that  it: 

(1)  calculates  results  to  any  desired  accuracy  and  precision, 

(2)  can  include  in  its  models  and  measure  the  significance  of 
all  system  elements  and  characteristics, 

(3)  relates  component  characteristics  to  system 
characteristics  using  classical  theory, 

(4)  provides  diagnostic  capabilities  to  analyze  the  cause  of 
any  peculiar,  unusual,  or  significant  system  event, 

(5)  models  and  rigorously  documents  system  configuration 
providing  traceability  and  repeatability, 

(6)  is  easy  to  use  by  engineers  not  specialized  in  statistics 
and  reliability  disciplines, 

(7)  is  an  accepted,  standardized  procedure  having  widespread 
application, 

(8)  is  not  limited  to  nor  restricted  by  a  simplified  "black 
box"  block-diagram  approach  which  ignores  many 
dependencies , 

(9)  replaces  error-prone  procedures  such  as  equation  writing 
and  other  manual  techniques, 

(10)  suppresses  unnecessary  intermediate  analysis  details  which 
are  difficult  to  interpret  (e.g.,  lengthy  equations, 
voluminous  fault  trees) , 

(11)  standardizes  baseline  models  providing  the  basis  for 
comparisons,  tradeoffs,  value  studies  and  uniformity  of 
interpretation, 

(12)  requires  less  analyst  time,  and  less  skilled  analysts, 
than  other  available  procedures  and  is,  consequently, 
more  efficient  and  cost-effective  than  similar 
procedures . 

Validation  of  GO  Methodology 

The  GO  methodology  has  been  repeatedly  compared  with  fault  tree 
methodology  and  has  demonstrated  that  it  provides  comparable,  and  more 
comprehensive,  results.  Some  of  the  studies  involving  such  comparisons 
are: 
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(1)  Comparison  of  Reliability  Evaluation  Methodologies, 

K74-83U(R),  3  July  1974,  Gale  B.  Curtis  (Nick  Zuck  - 

ARRADCOM) 

(2)  A  Comparison  of  Results  from  the  GO  Methodology  and  Fault 

Tree  Analysis,  NUREG-K77-38U(R) ,  31  August  1977,  D.  E. 

Wood  and  Noel  J.  Becar  (James  W.  Pitman  -  NRC) 

(3 )  Demonstration  of  a  Reliability  Assessment  Methodology  as 

Applied  to  Nuclear  Power  Plant  Systems,  K74-30U(R),  9 

April  1974,  R.  L.  Williams  and  Noel  J.  Becar  (Donald 

Eamon  -  DOE) 

(4)  GO  Evaluation  of  a  PWR  Spray  System,  EPRI  330-1,  August 

1973,  W.  T.  Long,  R.  L.  Williams  (Alexander  -  EPRI) 

(3)  Audit  and  Verfication  of  Existing  RAM  Assessments,  (1979) 

(U.S.  ARRADCOM  Contract  -  N.  Zuck) 

Acceptance  of  GO  Methodology 

The  GO  methodology  is  becoming  a  standard  assessment  procedure  for 
analyzing  the  safety  and  reliability  of  military  and  space  weapon  and 
communication  systems.  It  is  similarly  becoming  a  standard  availability 
and  probabilistic  risk  assessment  procedure  for  nuclear  and  conventional 
power  plants. 

The  Army  recently  completed  a  series  of  eight  GO  training  seminars  in 
which  138  Army  and  contractor  personnel  were  provided  hands-on  experience 
applying  the  GO  software  to  perform  assessments.  Similar  training  has  been 
conducted  for  utilities  beginning  with  a  training  session  in  Dallas,  Texas,  in 
July  1980. 

A  number  of  nuclear  plant  probabilistic  risk  assessments  are  presently 
being  conducted  using  the  GO  methodology,  e.g.,  Sequoyah,  Bellefonte. 
Availability  assessments  using  GO  have  also  been  performed  on  Midland, 
Sequoyah,  etc. 

The  recent  (April  1982)  draft  Procedures  Guide  for  Performing 
Probabilistic  Risk  Assessments  of  Nuclear  Power  Plants,  published  by  the 
Nuclear  Regulatory  Commission,  contains  several  pages  addressing  the 
strengths  of  the  GO  procedure.  The  Electric  Power  Research  Institute  is 
funding  GO-related  applications  at  the  rate  of  approximately  a  million 
dollars  a  year. 

KSC  has  received  inquiries  from  scientists  in  more  than  twenty  foreign 
countries  for  more  information  about  the  GO  methodology. 


Because  of  its  simplicity,  ease  of  use,  generality,  comprehensive 
capabilities,  efficiency,  and  lower  cost  of  application,  the  GO  methodology  is 
becoming  a  standard  state-of-the-art  method  for  performing  system  assessments. 
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Use  of  the  CAS/GO  methodology  by  trained  analysis  permits  refined  and 
comprehensive  system  assessments  accounting  for  all  dependencies  that  were 
intractable  several  years  ago.  Its  use  also  highlights  unfounded  assertions 
of  prior  studies  and  focuses  on  the  specific  data  required  to  generate  valid 
performance  measures.  Assessment  engineers  and  responsible  managers  should  be 
knowledgeable  of  this  latest  development  in  a  computerized  analysis 
methodology. 

Because  the  procedure  is  so  powerful,  managers  and  engineers  involved  in 
planning  for,  designing,  fabricating,  fielding,  and  assessing  the  performance 
of  any  major  system,  should  be  sufficiently  knowledgeable  of  the  GO 
methodology  to  take  advantage  of  its  unique  capabilities  to  aid  the 
decision-making  process.  GO  training  for  responsible  personnel  should  be 
provided  and  the  GO  software  and  its  documentation  should  be  acquired. 
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FOREWORD 


Background 

An  audit  and  verification  performed  on  existing  RAM  assessments  indicated 
numerous  differences  in  applying  various  mathematical  assessment  techniques 
and  developing  special  system  models.  Of  primary  importance,  the  audits 
demonstrated  the  need  for  a  baseline  computer-aided  assessment  methodology  to 
standardize  RAM  assessments  and  to  permit  the  development  of  more  accurate 
system  models. 

In  this  respect,  the  CAS  procedures  using  KSC  "GO”  methodology  were 
employed  to  perform  RAM  audit  assessments  and,  as  a  result,  uniquely 
demonstrated  a  qualified  computer-aided  assessment  technique  which  is  highly 
cost  effective  and  includes  many  advantages. 

The  differences  between  the  CAS  GO  methodology  and  the  failure  or  success 
equation  block  diagram  and  fault  tree  approaches  used  previously  in  RAM 
assessments  are  significant.  Some  of  the  more  significant  capabilities 
provided  by  the  computerized  GO  methodology  are: 

1.  Calculates  results  with  accuracy  and  precision 

2.  Includes  and  measures  the  significance  of  all  elements  and 
characteristics 

3.  Relates  component  characteristics  to  system 
characteristics  using  classical  theory 

4.  Provides  diagnostic  capabilities 

5.  Permits  traceability  and  repeatability 

6.  Is  not  limited  to  nor  restricted  by  the  "black  box", 
simplified  block-diagram  approach 

7.  Replaces  error-prone  procedures  such  as  equation  writing 
and  other  manual  techniques 

8.  Suppresses  unnecessary  intermediate  analysis  details  which 
are  difficult  to  interpret  such  as  lengthy  equations 

9.  Provides  standardized  or  baseline  models  as  a  basis  for 
comparisons,  tradeoffs,  value  studies,  and  uniformity  of 
interpretation. 

Development 

The  GO  software  was  initially  developed  by  KSC  scientists  Bill  Gateley, 
Larry  Williams,  and  Dan  Stoddard  under  Army  funding  in  1967.  With  the  passage 
of  time  the  codes  have  undergone  almost  continual  development  and  refinement 
by  the  KSC  originators.  In  the  early  70*  s,  a  number  of  new  features  were 
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added  -  data  consistency  checks,  new  operators  11-15,  supertypes,  sensitivity 
studies,  etc.  In  the  fall  of  1975,  KSC  conceived  the  fault-finder  and 
confidence  interval  algorithms.  These  were  subsequently  implemented  with 
internal  IR&D  funds,  continuing  Army,  Navy,  and  NRC  funding  and  EPRI  funding. 

Because  of  the  unique  formulation  of  the  GO  methodology  and  its  modeling 
approach,  its  use  and  acceptance  are  widespread.  Users  of  various  versions  of 
the  codes  include  the  Army  Research  and  Development  Command,  Eglin  Air  Force 
Base,  Boeing-Wichita ,  University  of  Washington,  Bechtel  Power  Company,  Brown  & 
Root,  Inc.,  Utah  Power  and  Light  Company,  Tennessee  Valley  Authority, 
Cincinnati  Gas  and  Electric  Company,  San  Diego  Gas  and  Electric  Company, 
Houston  Power  and  Light  Company,  Pickard,  Lowe  and  Garrick,  Inc.,  etc.  The 
latest  version,  KSC  GO  Version  1.0,  is  also  on  the  Control  Data  Corporation 
(CDC)  CYBERNET  timeshare  system. 

With  many  users  and  increased  application  there  is  a  continuing  need  for 
code  updates  and  modif ications.  There  is  also  need  for  continuing  support  and 
standardized  versions  of  the  codes  which  KSC  as  the  originators  and  most 
experienced  users  continues  to  provide. 

Since  the  original  creation  of  the  GO  codes  in  1967  there  have  been  24 


documented  KSC 

DATE 

versions  of 

NAME 

the  codes  as  shown  below. 

VERSIONS  OF  THE  GO  CODES 

CHARACTERIZATION 

APR  68 

GOMAR68 

Eleven  Logical  Operators,  Hash  Addressing 

JUN  68 

G0JUN68 

— 

APR  69 

GOAP69 

Type  9  &  11  Kind  Data  Changed,  Sensitivity  Runs, 
Format-free  Data,  Modular  Programs,  Time  Points 
up  to  9999  permitted 

MAY  69 

GOMAY69 

Use  of  two  computer  words  to  store  more  active 
signals  and  handle  larger  problems 

AUG  70 

GOAUG70 

— 

1971 

RANGO 

Randomized  GO,  Component  Beta  Distributions 

1972 

GOCHK72 

— 

APR  7  A 

GOAPR74 

Data  Checks,  Signal  Table 

1974 

XGO 

100  Active  Components,  Automatic  Signal 
Deletion,  Extensive  Error  Checking,  Perfect 
Component  Case,  Automatic  Array  Size 
Optimization,  PMIN  Reset,  Types  5  &  11  Combined 

1975 

Version  B 

_ 
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VERSIONS  OF  THE  GO  CODES  (Continued) 


DATE  NAME 

CHARACTERIZATION 

16  FEB  76  Version  C 

New  Operators  11-15,  Multiple  Type  8  Delays,  G01 
Signal  Table,  Developed  with  Public  Funds 

26  APR  76  Version  D 

Supertypes  GOl,  G02,  G03,  Printouts  Modified, 

GOl  Signal  Table,  Developed  with  Public  Funds 

NOV  76  Version  E  - 


11  JAN  77 

Preliminary  Fault  Finder 

3  MAY  77  GO 

Fault  Finder  SYSFILE,  FFl ,  FF2 

30  NOV  77  GO 

Types  16  &  17 

3  MAR  78 

Version  D  as  documented  for  EPRI,  Master  Program 
GOFF,  Data  Decks  Control  Sequence,  Alpha 
Descriptors,  New  Type  4 

1  DEC  78  GOFF 

Program  FGO  &  G04  Created 

17  AUG  79  GO 

Efficiency  Update,  New  Program  Structure, 

Procedures  and  CLISTS,  LIBRARY  GORUN 

1  OCT  79  GO 

Effect  Evaluation  EE1,  EE2 ,  EE3 

20  MAR  80  GO 

CDC  Version  Documented  for  EPRI 

20  MAY  80  GO 

IBM  Version  Documented  for  B&R,  UP&L,  EPRI 

30  DEC  80  GO 

IBM  Version  Enhanced  at  UCC,  Dallas, 
Descriptors,  Facility  To  Alter  Array  Sizes, 
Explanation  Of  Use 

1  SEP  82  KSCGO 

Version  1.0  Proprietary  to  KSC,  Both  VAX  and 
CYBER  Versions,  Developed  directly  from  GO 
Version  C,  1976 

Like  most  well-used  software  the  GO  codes  have  been  continually  changed 
and  modified.  In  1979-80  under  the  sponsorship  of  Utah  Power  and  Light 
Company  and  EPRI  the  GO  codes  were  converted  from  the  Control  Data  Corporation 
Fortran,  in  which  the  most  recent  version  had  been  written,  to  IBM  Fortran. 
KSC  accomplished  this  task  and  documented  both  the  CDC  and  IBM  versions  of  the 
codes  as  they  existed  in  1980.  In  1982,  KSC  on  its  own  initiative  and  funding 
developed  a  new  proprietary  version  of  the  GO  programs.  Using  the  1976  public 
domain  Version  C  of  GO,  KSC  scientists  have  created  the  latest  version  called 
KSC  GO,  Version  1.0,  September  1,  1982.  This  latest  version  of  GO  is 
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available  from  KSC  in  both  VAX-11  and  CYBER  versions.  The  VAX-11  version  can 
be  readily  converted  to  IBM  systems  and  has  the  added  capability  of 
word-packing  to  increase  efficiency  and  reduce  disk  access  requirements.  This 
feature  was  not  a  part  of  the  former  IBM  version  of  the  code.  An  additional 
capability,  which  takes  advantage  of  the  large  main  memory  of  the  VAX,  is  that 
array  sizes  can  be  increased  to  20,000  or  more  (vs.  the  3000-5000  array  sizes 
on  former  versions)  to  effect  orders  of  magnitude  error  reduction  for  large 
problems . 

There  are  a  number  of  other  additional  new  features  to  KSC  GO,  Version 
1.0.  In  particular  the  fault  finder  algorithm  is  completely  new  and  is  no 
longer  tied  to  probabilities.  These  new  features  are  fully  documented  in 
complementary  publications. 
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CHAPTER  1 

ASSESSMENT  OBJECTIVES 


INTRODUCTION 

The  objectives  of  a  probabilistic  system  assessment  must  be  defined 
before  commencing  the  work.  A  number  of  factors  must  be  considered  to  clearly 
define  the  objectives.  In  this  chapter  we  discuss  some  of  the  factors  which 
must  be  considered. 


System  Events  and  Their  Probabilities  of  Occurrence 

A  fundamental  question  to  be  asked  about  a  system  is,  "What  do  we  want  to 
know  that  we  don't  already  know?"  If  the  answer  to  that  question  is,  "We  want 
to  know  the  probabilities  of  occurrence  of  certain  system  events,"  then  it  may 
be  desirable  to  construct  a  system  GO  model  to  calculate  these  probabilities. 
If  the  system  has  a  well-defined  configuration  and  if  pertinent  component  data 
can  be  obtained,  then  GO  models  can  be  developed  to  answer  specific  questions. 

The  KSC  GO  methodology  is  used  to  generate  system  events  and  their 
probabilities  of  occurrence  from  the  defined  interrelationships  of  external 
inputs  and  boundary  conditions,  constituent  elements  and  components  and  the 
probabilities  associated  with  their  possible  operational  states.  The 
methodology  is  used  additionally  to  identify  sets  of  component  failures  which 
singly  or  in  combination  cause  system  failures.  Another  principal  use  is  to 
study  the  effects  upon  system  performance  caused  by  changes  in  or 
uncertainties  about  component  probabilities  of  performance. 

System  Performance  Measures 

In  the  foregoing  paragraphs  the  terms  "system,"  "performance,"  and  "data" 
have  been  purposely  left  vague.  We  now  proceed  to  define  them  more  carefully. 

A  system  is  any  collection  of  basic  elements  (including  human  actions) 
which  are  arranged  in  a  definite  configuration  and  which  interact  to  produce 
at  least  one  output  event  of  interest.  This  definition  is  broad.  Examples  of 
systems  are  household  appliances,  automobiles,  industrial  plants,  power 
plants,  missile  systems,  airplanes,  satellites,  communication  networks,  etc. 

System  performance  is  often  measured  using  standard  terms  like 
reliability  and  availability.  Definitions  for  these  terms  are: 

Reliability  is  "the  characteristic  of  an  item  expressed  by 
the  probability  that  it  will  perform  a  required  mission 
under  stated  conditions  for  a  stated  mission  time"  (IEEE 
Std .  577-1976). 

Availability  is  "the  characteristic  of  an  item  expressed 
by  the  probability  that  it  will  be  operational  at  a 
randomly  selected  future  instant  in  time"  (IEEE  Std. 

577-1976). 
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Safety  and  risk  also  are  couched  in  terms  of  the  probability  of 
occurrence  of  catastrophic,  hazardous  or  destructive  events. 

The  objective  of  a  system  assessment  is  almost  always  the  determination 
of  the  reliability,  availability,  safety,  risk,  or  hazard  associated  with  the 
design,  fabrication,  and  use  of  a  system.  Because  each  of  these  measures  is  a 
probability,  system  performance  is  almost  always  expressed  as  the  probability 
of  occurrence  of  specific  system  events.  The  GO  methodology  was  developed  to 
calculate  such  probabilities. 

Data 

Different  system  performance  measures  require  different  types  of 
component  data.  To  generate  system  availability  estimates  requires  estimates 
of  component  availabilities.  To  develop  system  reliability  estimates  requires 
component  reliability  estimates,  etc. 

In  all  cases,  however,  system  GO  models  require  component  probability 
point  estimates  as  contrasted  with  probability  distributions.  For  example, 
consider  a  component  which  exhibits  three  mutually  exclusive  modes  of 
operation,  e.g.,  premature,  normal  or  proper,  and  failure.  Data  for  this 
component  may  establish  that  the  probabilities  of  the  component  taking  these 
operational  states  are  0.001,  0.997,  and  0.002  respectively.  These 
reliability  point  estimates  are  provided  to  the  computer,  along  with  similar 
data  for  other  components  to  generate  reliability  point  estimates  for  system 
events . 

For  an  availability  study,  components  will  have  only  two  states,  i.e., 
available  or  unavailable.  A  given  component  may  have  an  availability  point 
estimate  of  0.9999  and  a  corresponding  unavailability  point  estimate  of  0.0001 
(1-0.9999).  Using  such  data  for  all  constituent  model  elements  the  GO 
software  will  generate  system  availability  point  estimates. 

Probabilities  associated  with  human  actions  and  decisions  are  often 
included  in  GO  models  to  account  for  such  effects.  These  also  are  input  in 
the  form  of  point  estimates. 

Data  for  a  GO  model  is  a  collection  of  pertinent  probability  point 
estimates  that  aptly  describe  the  probabilistic  behavior  of  the  basic  model 
elements.  Often  the  level  of  resolution  to  which  a  GO  model  is  developed 
depends  upon  the  component  data  available. 

Standard  reference  sources  exist  documenting  generic  data  for  most  types 
of  equipment,  e.g.,  electrical  components,  pumps,  valves,  instrumentation. 
MIL-HDBK-217B ,  GIDEP,  National  Power  Reactor  Data  System  (NPRDS) ,  and  IEEE 
Std.  500-1977  Nuclear  Reliability  Data  Manual  are  representative  of  available 
data  sources. 
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Assumptions  and  Boundaries 

All  studies  are  limited  by  time  and  dollar  constraints.  To  clarify  the 
scope  and  intent  of  an  analysis,  the  explicit  and  implicit  assumptions  made  in 
developing  a  model,  even  though  "obvious"  or  "universal,"  should  be  clearly 
stated.  The  fact  that  only  a  certain  subsystem  is  being  analyzed,  that  all 
electrical  and  human  inputs  are  considered  perfect,  that  no  out-of-tolerance 
or  beyond-limit  stresses  have  been  postulated,  etc. ,  should  be  clearly  stated. 
This  focuses  attention  on  what  is  being  analyzed  and  aides  in  interpreting  and 
stating  the  study  results. 

Success  and  Failure  Criteria 

To  develop  a  model  which  faithfully  represents  a  system  requires  a  clear 
definition  of  what  constitutes  both  system  success  and  system  failure. 
Determining  the  criteria  for  success  and  failure  usually  simplifies  the  task 
of  model  development  and  sharpens  the  focus  on  the  study  objective. 

Limitations  and  Uncertainties 

Studies  are  limited  in  many  ways.  Time  does  not  permit  the  accumulation 
of  more  data.  The  exact  configuration  is  not  known.  The  effect  of  certain 
component  failures  is  not  defined.  Excluding  analyst  error,  uncertainties 
result  from  lack  of  knowledge.  Data  uncertainties  are  often  treated  using 
data  ranges,  and  expressing  the  results  in  terms  of  confidence  intervals 
rather  than  precise  point  estimates.  Configuration  and  component  response 
uncertainties  are  treated  by  developing  several  models  to  handle  the  most 
likely  situations  and  portray  the  differences  caused  by  different 
conf igurations  and  component  responses.  The  recognition  and  treatment  of 
limitations  and  uncertainties  will  enhance  the  value  of  a  study  and  will  help 
clarify  the  assessment  objective. 

Design  Enhancement 

Having  quantified  system  performance  and  taken  into  account  knowledge 
deficiencies  and  uncertainties,  an  often  fruitful  approach  expanding  the  study 
is  to  identify  major  causes  of  degradation  or  failure.  Once  identified  these 
effects  can  often  be  mitigated  with  improved  quality  control  or  by  design 
changes.  The  beneficial  effects  of  such  improvements  or  design  changes  can  be 
objectively  determined  and  reported  by  making  the  changes  to  the  model  and 
rerunning  it.  Consequently,  the  study  objective  may  be  to  determine  how  a 
system  can  be  improved  to  achieve  a  certain  level  of  performance. 

The  scope  of,  and  available  resources  for,  the  study,  the  schedule  in 
which  it  must  be  completed,  and  the  end  product  to  be  produced  are  additional 
considerations  which  help  define  the  assessment  objectives. 

From  a  technical  point  of  view  the  most  important  considerations  in 
defining  the  study  objective  are  the  performance  measures  wanted,  the  system 
definition,  the  data  required,  and  the  assumptions  and  boundary  conditions  to 
be  used. 
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It  is  difficult,  if  not  impossible,  to  develop  models  and  perform 
assessments  when  the  study  objectives  are  not  clearly  defined.  As  you  read 
the  remaining  chapters  of  this  primer  and  become  familiar  with  the  KSC  GO 
methodology,  focus  on  the  objectives  for  which  various  example  GO  models  are 
developed.  Doing  so  will  help  you  catch  the  essence  of  the  procedure  and 
illuminate  the  software  capabilities.  Defining  the  objectives  to  be  achieved 
by  developing  GO  system  models  will  aid  you  in  applying  the  procedure  to  real 
world  problems  of  your  own. 
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CHAPTER  2 
EVENT  TREES 


Introduction 

Every  person  who  has  engaged  in  problem  solving  exercises  has  employed 
branching  diagrams  or  event  trees.  The  purpose  of  this  chapter  is  to 
illustrate  how  event  trees  are  used  to  solve  reliability  problems.  This 
discussion  is  a  preamble  to  using  the  GO  methodology.  The  GO  computer 
programs  automate  the  process  of  creating  and  manipulating  event  trees.  Their 
efficient  use  permits  the  creation  and  manipulation  of  event  trees  of  almost 
any  size. 

The  Coin  Flip  Problem 

Let  us  presume  we  flip  a  coin  four  times.  Five  possible  outcomes  result, 
i.e.,  0,  1,  2,  3,  or  4  heads.  We  desire  to  determine  the  probabilities  of 
obtaining  each  of  these  elemental  outcomes. 

We  can  formalize  the  procedure  by  defining  a  random  variable  X  to  be 
the  number  of  heads  obtained  in  the  experiment.  As  noted  above,  the  random 
variable  X  can  take  any  of  five  different  values.  The  problem  then  is  to 
determine  the  probability  that  X  takes  each  specific  value,  i.e.,  Pr(X=i)  = 
?,  i  =  0,1, 2, 3, 4.  In  summary  we  desire  to  complete  the  following  figure 
(Figure  1). 


VALUE 

X  TAKES 

PROBABILITY 

0 

? 

1 

? 

2 

? 

3 

? 

4 

? 

FIGURE  1  PROBABILITY  MASS  FUNCTION 
FOR  RANDOM  VARIABLE  X 

This  problem  can  be  readily  conceptualized  with  an  event  tree  (see  Figure 
2).  Each  flipping  operation  doubles  the  branches  in  the  tree.  Ultimately  the 
tree  has  16  mutually  exclusive  terminal  branches. 

The  event  tree  is  converted  to  a  probability  tree  by  introducing  the 
probabilities  associated  with  each  of  the  two  possible  outcomes  for  each  of 
the  four  independent  experiments.  We  assume  there  is  an  equally  likely  chance 
that  either  a  head  or  a  tail  outcome  occurs  on  each  flip.  Consequently  each 
has  a  0.5  probability  of  occurring.  Because  each  outcome  is  equally  likely 
each  of  the  sixteen  terminal  branches  have  an  equal  likelihood  of  occurring, 
namely  (.5)  =  0.0625. 

Note  on  Figure  2  that  only  one  terminal  branch  produces  four  heads. 
Consequently,  the  probability  of  obtaining  four  heads  is  0.0625.  The  same  is 
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FIGURE  2  EVENT  TREE  FOR  COIN  FLIP  PROBLEM 
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true  for  zero  heads.  There  are  four  terminal  branches  resulting  in  three 
heads,  so  the  probability  of  this  outcome  is  4x0.0625=0.25.  Similarly  there 
are  four  terminal  branches  producing  one  head.  Finally  there  are  six  terminal 
branches  producing  two  heads  with  probability  of  occurrence  6x0.0625=0.3750. 


The  table  for  the  probability  mass  function  for  X  can  now  be  completed 
from  the  event  tree  solution*  to  this  problem. 


VALUE 

X  TAKES 

PROBABILITY 

0 

0.0625 

1 

0.2500 

2 

0.3750 

3 

0.2500 

4 

0.0625 

TOTAL 

1.0000 

FIGURE  3  PROBABILITY  MASS  FUNCTION 
FOR  RANDOM  VARIABLE  X 

Switch  Operation  Analysis  By  Event  Tree 


We  move  now  to  a  less  obvious  analysis  using  the  event  tree  approach. 
Consider  the  operation  of  a  simple  switch  as  shown  below: 


I 

i 

Y 


FIGURE  4  SWITCH 

The  main  electrical  input  to  the  switch  is  shown  as  random  variable  X,  which 
takes  possible  values  0,  1,  and  ®  representing  the  times  of  arrival  of  input 
power  to  the  switch.  The  mechanical  actuation  of  the  switch  is  shown  as 
random  variable  Y,  which  similarly  takes  values  of  1  and  <»  indicating  the 
times  at  which  the  switch  is  actuated.  Given  that  the  probability  mass 
functions  for  both  X  and  Y  are  known,  find  the  probability  mass  function 
for  dependent  random  variable  Z,  whose  values  represent  the  times  at  which 
output  power  is  available  from  the  switch. 


*  For  this  trivial  problem  there  are  a  number  of  solution  methods.  Perhaps 
the  most  straightforward  is  the  binomial  expansion  of 
(H  +  T)4  =  H4  +  4H3T  +  6H2T2  +  4HT3  +  T4  where  H  is  the  probability  of 
obtaining  a  head  and  the  exponent  on  H  is  the  number  of  heads  in  that  term. 
The  same  nomenclature  is  used  for  tails.  Since  H=T=l/2  in  this  problem  the 
result  is  immediate. 
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First  we  define  the  following  events: 


=  Event  that  power  is  applied  to  switch  at  relative  time  i. 

Y.  =  Event  that  the  switch  is  actuated  at  relative  time  i. 

1 


Z.  =  Event  that  power  is  received  from  the  switch  at  relative 
time  i. 


The  probability  mass  functions  for  random  variables  X  and  Y  are 
defined  in  the  figure  below  where  the  possible  times  (or  values  the  random 
variables  take)  are  0,  1,  and  oo .  In  this  case  infinity  means  ’never' ,  i.e., 
power  never  arrives  or  the  switch  is  never  actuated,  zero  .means  before  the 
intended  time  of  operation,  and  1  means  the  time  of  intended  operation 
(power  arrival  and  switch  actuation) . 


i 

P(x.) 

1 

i 

P(Y.) 

0 

.  1 

1 

.8 

1 

.5 

00 

.2 

00 

.4 

FIGURE  5  PROBABILITY  MASS  FUNCTIONS 
FOR  DISCRETE  RANDOM  VARIABLES  X  AND  Y 


If  the  switch  itself  is  perfect,  the  event  tree  of  Figure  6  shows  the 
solution  to  this  problem.  Six  unique  joint  events  result  from  the  combination 
of  the  two  independent  random  variables  X  and  Y  taking  their  respective 
values.  The  resultant  values  assumed  by  random  variable  Z  are  1  and  oo  9 
meaning  that  the  switch  provides  electrical  power  at  time  1  with  probability 
0.48  and  that  it  fails  to  provide  an  output  (i.e.,  provides  an  output  at 
time  oo  or  never)  with  probability  0.52. 

Now,  instead  of  presuming  that  the  switch  is  perfect,  let  us  presume  that 
it  has  three  operational  states'  —  good  (g) ,  failed  (f ) ,  and  premature  (p)  and 
that  it  takes  on  these  states  with  probabilities  0.7,  0.2,  and  0.1, 
respectively.  When  the  probabilistic  behavior  of  the  switch  itself  is 
additionally  considered,  the  six  joint  events  resulting  from  the  times  of 
arrival  of  input  power  (random  variable  X)  and  the  time  of  actuation  (random 
variable  Y)  expand  to  18  joint  events. 

The  event  tree  for  the  case  of  an  imperfect  switch  is  shown  in  Figure  7. 
Note  that  now  there  are  three  possible  outcomes  for  random  variable  Z.  It 
can  take  values  0,  1,  and  «  .  In  this  case  a  value  of  0  means  a  premature 
electrical  output  from  the  switch  which  can  only  occur  if  input  power  is 
premature  (X  )  and  the  switch  is  prematurely  electrically  continuous 
(shorted).  Now  the  output  distribution  for  Z  is: 


8 
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FIGURE  6  EVENT  TREE  FOR  PERFECT  SWITCH 
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P(Z  )  =  0.010, 

P<zr)  =  0.386, 

P(Z«)  =  0.604. 

For  this  relatively  trivial  problem,  18  possible  unique  joint  events 
involving  the  three  random  variables  (X,  Y  and  the  switch)  resulted.  For  a 
system  of  many  components  the  event  trees  become  very  large.  Consequently,  to 
keep  the  trees  manageable  in  size,  terms  with  smallest  probabilities  of 
occurrence  are  often  discarded.  This  is  done  by  specifying  a  probability 
value  (PMIN)  and  discarding  (pruning)  all  terms  (branch)  combinations  whose 
probabilities  of  occurrence  are  less  than  this  preassigned  value.  Even  if  the 
event  trees  are  generated  automatically  using  a  computer  it  is  generally 
necessary  to  prune  the  trees  if  the  number  of  system  components  is  more  than  a 
few  dozen. 

In  the  event  tree  for  the  imperfect  switch  (Figure  7),  the  branches  with 
dashed  l^nes  leading  to  the  Z  events  would  have  been  eliminated  with  a  PMIN 
of  5x10  .  The  probabilities  of  occurrence  of  final  Z  events  are  reduced 
by  the  probabilities  of  the  discarded  terms  an^  some  error  is  introduced.  In 
this  oroblem  note  that  a  total  error  of  6x10  is  introduced  with  a  PMIN  of 
5x10  . 


Even  though  this  is  undesirable,  when  large  systems  with  hundreds  of 
components  are  analyzed,  the  introduction  of  some  relatively  small  error  is  a 
proper  tradeoff  for  having  a  tractable  problem.  Experience  has  shown  that 
with  some  skill  in  structuring  the  trees,  the  error  can  be  made 
insignificantly  small  in  almost  all  cases,  while  permitting  economical 
computer  manipulation  of  very  large  trees. 
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CHAPTER  3 

THE  GO  METHODOLOGY 


INTRODUCTION 

The  GO  methodology  is  an  automated  way  to  develop  system  event  tree 
models.  Such  models  are  developed  to  analyze  the  probabilistic  behavior  of 
systems  defined  by  such  terms  as  reliability,  availability,  safety  and  risk. 
GO  models  are  developed  using  standard  logical  operators  to  represent  system 
equipment  and  components,  their  operations  and  interactions.  Appropriate 
probability  data  for  equipment  performance,  human  actions,  and  external  events 
are  gathered  and  tabulated.  A  GO  model  and  its  associated  probability  data 
are  then  placed  on  computer  data  input  files  which  are  accessed  and  processed 
by  the  GO  computer  programs  to  develop  the  event  trees  whose  terminal  branches 
contain  the  desired  system  events  and  their  probabilities  of  occurrence. 

GO  Operators  (Types) 

The  heart  of  the  GO  process  is  the  definition  of  fifteen  standard  logical 
operator  "types"  which  are  used  to  represent  model  elements  and  interactions. 
For  example,  a  type  1  operator  represents  the  logical  operation  of  an 
equipment  which  either  performs,  or  fails  to  perform,  its  function  given  a 
proper  input  or  stimulus.  The  type  2  operator  performs  the  logical  OR  gate 
operation  where  a  successful  response  is  generated  if  any  of  several  inputs  is 
proper,  etc. 

The  fifteen  logical  operators,  for  which  algorithms  are  defined  in  the  GO 
codes,  are  depicted  in  Figure  8.  Figure  8  also  shows  the  symbol  normally  used 
to  define  the  operators.  Operator  inputs  are  called  stimuli  (S  f  S  ,  ...  S  )* 
and  outputs  are  called  responses  R  )  -  Such  inputs  and  outputs 
are  random  variables.  An  operator*  which  represents  equipment  responses  or 
human  actions,  and  which  may  itself  have  associated  performance  probabilities, 
processes  the  input  random  variables  in  a  prescribed  and  well-defined  way  to 
generate  the  output  random  variables.  In  GO  models  these  random  variables  are 
called  "signals",  a  carryover  from  electrical  terminology. 

GO  Models 

A  GO  model  is  developed  directly  from  electrical  schematics,  engineering 
blueprints,  and  flow  diagrams  by  substituting  the  standardized  GO  operators 
for  physical  equipment,  human  actions  and  logical  operations.  The  inputs  and 
outputs  to  these  operators  are  combined  and  arranged  to  show  the  logical 
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FIGURE  8  GO  OPERATOR  TYPES 


configuration  or  process  flow  necessary  for  successful  operation  of  the 
systems.  The  GO  models  thus  appear  similar  to  the  original  schematic, 
blueprint  or  flow  diagram  and  capitalize  upon  the  analyst’s  familiarity  with 
the  configuration  and  the  proper  intended  operation  of  the  system.  This 
similarity  to  such  diagrams  aids  in  validating,  understanding  and  interpreting 
the  models. 

The  steps  in  creating  a  GO  model  are:  (1)  learn  how  the  system  is 
configured  and  actually  operates;  (2)  define  system  success  and  failure 
criteria;  (3)  identify  the  system  events  about  which  information  is 
sought;  (4)  represent  system  elements  with  standardized  GO  operators; 
(5)  combine  the  inputs  and  outputs  of  operators  representing  system 
elements  into  a  GO  model  portraying  successful  system  operation;  (6) 
obtain  the  probabilistic  data  for  component  responses. 

To  illustrate  how  this  is  done,  consider  the  example  system  of  Figure 
9.  An  electrical  cord  is  plugged  into  a  wall  circuit.  Subsequently  Sam  turns 
on  the  switch  to  a  motor.  Question:  What  is  the  probability  that  the  motor 
begins  operating  when  Sam  turns  on  the  switch?  The  answer  to  this  question 
is  a  function  of  the  availability  of  power,  the  electrical  continuity  of  the 
plug  and  cord,  the  reliability  of  the  switch,  whether  or  not  Sam  actually 
turns  the  switch  on,  and  the  reliability  of  the  motor. 


FIGURE  9  EXAMPLE  SYSTEM 


A  GO  diagram  for  this  system  is  shown  in  Figure  10.  The  symbols  for  the 
standard  GO  operator  types  are  used  to  represent  each  system  element.  Inside 
each  symbol  is  a  hyphenated  number.  In  each  case  the  first  number  specifies 
the  operator  type.  The  second  number,  called  the  "kind"  number,  references 
the  probability  data  associated  with  this  operator.  It  will  be  addressed  in 
the  next  section. 


FIGURE  10  EXAMPLE  GO  MODEL 
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Each  operator  input  and  output  is  given  a  "signal11  (random  variable) 
number.  For  example  the  availability  of  power  is  represented  in  this  model  by 
signal  #lf  the  output  from  the  type  5  operator  representing  the  availability 
of  electric  power.  The  output  from  the  type  1  operator  representing  the  plug 
is  signal  #2,  etc.  Signal  #5,  the  output  from  the  type  1  operator 
representing  the  motor,  is  the  final  signal  generated  by  the  model.  In  fact, 
the  model  was  developed  to  generate  the  probability  mass  function  for  signal 
#5  to  allow  us  to  quantify  the  probability  of  motor  operation  in  this  system. 

G01  Operator  Data 

Figure  11  shows  the  format  for  communicating  the  operator  type,  the 
associated  kind  data  reference,  and  the  input  and  output  signal  numbers  to 
computer  program  G01  as  shown  in  Figure  11.  To  record  the  operator  data  for  a 
specific  component,  the  operator  type  is  written  first,  next  the  kind  number 
(K)  is  generally  written,  then  the  input  signal  number  or  numbers  (S.) 
are  written  followed  by  the  output  signal  number  or  numbers  (R.).  For  example 
the  information  concerning  the  plug  in  the  GO  model  of  the  example  system 
(Figure  10)  is  communicated  to  the  computer  in  the  form, 

1  10  1  2  $  PLUG 

This  tells  the  computer  that  we  have  a  type  1  operator  with  kind  10 
probabilities.  It  has  signal  #1  as  an  input  and  generates  signal  #2  as  an 
output.  The  dollar  sign  ($)*  is  a  data  terminator  and  the  description  to  the 
right  of  the  terminator  is  optional.  Obviously  a  signal  cannot  be  used  as  an 
input  until  it  has  been  created  as  an  output  by  some  prior  operator. 

The  entire  set  of  G01  data  for  the  example  system  is  recorded  in  the 
following  eight  lines: 


G01  DATA  FOR  EXAMPLE  SYSTEM 
$PARAM  INFIN=3  $ 

5  50  1  $  ELECTRIC  POWER 
1  10  1  2  $  PLUG  &  CORD 

5  51  3  $  SAM 

6  60  2  3  4  $  SWITCH 
1  11  4  5  $  MOTOR 

0  5  $  FINAL  OUTPUT  SIGNAL 

The  first  line  of  data  is  a  model  name  or  header  card.  The  second  line 
of  data  calls  up  a  Fortran  namelist  parameter  named  PARAM  which  permits  the 
initialization  of  several  parameters.  In  this  model  only  the  parameter  INFIN, 
meaning  the  largest  value  a  random  variable  may  take,  is  specified.  Default 
values  are  used  for  several  other  G01  parameters  which  can  be  defined,  e.g., 
BIAS,  OP,  SIGNAL.  (See  the  GO  Reference  Manual  for  full  exposition  of 
parameters) . 


*  Some  versions  of  GO  use  a  slash  (/)  as  a  terminator. 
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1  K  S  R 

2  0  n  S-...S  R 

I  n 

3  K  S  R 

4  K  n  R^...Rn 

5  K  R 

6  K  S1  S2  R 

7  K  S1  S2  R 

8  K  S  R 

9  K  S1  S2  R 

10  0  n  S1...Sn  R 
limn  S<|...Sn  R 

12  K  S  m  Ri...R„ 

l  m 

13  K  n  Sq...Sn  m  R^...Rn 

14  K  n  Sr..Sn  R 

15  K  S  R 

K:  KIND  NUMBER 

S:  STIMULUS  (INPUT)  SIGNAL  NUMBER 
R:  RESPONSE  (OUTPUT)  SIGNAL  NUMBER 

SEE  THE  GO  REFERENCE  MANUAL  FOR 
COMPLETE  DESCRIPTION  OF  INPUT  DATA 


FIGURE  11  GOI  OPERATOR  DATA 
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After  the  header  and  parameter  cards,  the  operator  data  is  entered,  one 
operator  per  line.  The  G01  operator  data  completely  defines  the  logical 
nature  of  the  model  elements  and  their  interactions.  The  G01  data  thus 
documents  the  system  configuration. 

In  this  model  there  are  five  operators.  The  first  operator,  which 
represents  the  availability  of  electric  power,  is  a  type  5  operator.  It 

references  kind  50  probabilities  and  generates  signal  #1.  Then,  in 
succession,  we  have  a  type  1  kind  10  operator  representing  the  plug  and 
cord,  a  type  5  kind  51  operator  representing  Sam,  a  type  6  kind  60 
operator  representing  the  switch,  and  a  type  1  kind  11  operator 

representing  the  motor. 

The  output  from  the  motor  is  signal  #5.  This  is  the  final  signal  whose 
distribution  we  desire  to  see  in  the  computer  results.  We  tell  the  G01 
software  that  signal  #5  is  the  signal  to  appear  in  the  output  with  the  last 
line  of  entry.  The  use  of  a  n0n,  instead  of  an  operator  type,  flags  the 
computer  that  this  entry  terminates  the  G01  data  and  that  the  following 

entries  on  that  line  are  signals  which  are  to  appear  in  the  final  output 

distribution.  In  this  case  only  the  single  signal,  #5,  is  requested. 

GO  Values  and  Event  Definitions 

An  important  consideration  in  developing  GO  models,  not  obvious  in  the 
discussion  to  this  point,  is  the  specification  and  meaning  of  the  possible 
values  that  the  random  variables  may  take.  Recall  that  in  the  coin  flip 
example  of  the  random  variable,  number  of  heads  obtained  in  four  flips,  could 
take  any  of  the  five  possible  values  -  0,  1,  2,  3,  or  4. 

Similarly  in  every  GO  model  the  possible  values  which  the  random 

variables  (signals)  may  take  must  be  specified.  The  model  is  clarified  by 
attaching  a  meaning  and  definition  to  each  value. 

For  example  if  one  desires  to  know  whether  a  system  functions  or  fails  to 
function,  two  values  would  be  sufficient.  In  such  a  GO  model  these  would  be 
the  values  0  and  1.  The  value  0  would  mean  success  and  the  value  1,  failure. 

To  pursue  this  concept  further,  let  us  define  some  values  for  the  GO 

model  of  the  example  system  of  Figures  9  and  10.  For  the  purpose  of 
illustration  let  there  be  four  possible  values  with  definitions  as  shown  in 
Figure  12. 


0  -  All  prior  time 

1  -  Time  when  electric  power  is  available  in  wall  socket 

2  -  Time  when  Sam  turns  on  switch 

3  -  Never _ 

FIGURE  12  VALUES  FOR  EXAMPLE  SYSTEM 
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With  these  definitions  we  see  that  the  random  variables  will  take  values 
which  reference  a  relative  time  sequence.  Having  defined  these  values  for 
this  model,  the  meaning  of  random  variable  #5  taking  value  2,  5_*»  means  the 
event  that  the  motor  turns  on  when  Sam  turns  on  the  switch.  Similarly,  event 
5^>  means  the  motor  never  turns  on,  or  fails  to  turn  on,  etc. 

For  the  example  system  some  additional  events  which  may  be  defined 
are  listed  in  Figure  13. 


EVENT  EVENT  DEFINITION 


1  POWER  IS  AVAILABLE  TO  THE  PLUG  AT 

TIME  1 

2  POWER  IS  AVAILABLE  FROM  THE  PLUG  AT 

TIME  1 

3 ^  SAM  OPERATES  SWITCH  AT  TIME  2 

4  POWER  IS  AVAILABLE  FROM  THE  SWITCH  AT 

TIME  2 

43  POWER  IS  NEVER  AVAILABLE  FROM  THE  SWITCH 

5  THE  MOTOR  OPERATES  WHEN  SAM  TURNS  ON 

THE  SWITCH 

53  THE  MOTOR  FAILS  TO  OPERATE 

FIGURE  13  SOME  EVENTS  DEFINED  FOR  EXAMPLE  PROBLEM 

G02  Probability  Data 


The  probability  data  required  for  a  GO  model  is  specific  to  that  model. 
It  is  entered  by  specifying  an  arbitrary  kind  number  which  permits  reference 
to  the  data.  The  form  in  which  the  data  is  entered  is  determined  by  the  type 
of  operator  which  calls  for  the  data.  Figure  14  depicts  the  format  in  which 
the  probability  data  for  each  operator  type  will  be  entered. 


The  arbitrary  kind  numbers  are  represented  by  K  in  the  figure.  The 
probabilities  of  good,  bad,  and  premature  component  operation  are  represented 


as  P 


g 


P^ ,  and  Pp  respectively. 


Values  are  represented  with  V. 


The  probability  data  associated  with  a  type  1  operator  is  provided 
to  computer  program  G02  in  the  form: 


KIP  PL 
g  b 


*  We  adopt  the  nomenclature  that  events  are  defined  by  signal  numbers 
subscripted  with  specific  values. 
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K 

1 

P9 

pb 

K 

3 

pg 

pb 

PP 

K 

4 

n 

m  Vlv. 

■Vm  P1 

V2V 

■  V2n  P2 

Vm1- 

■  *  ^mn  Pi 

K 

5 

n 

V1 

Pi.. 

•Vn  Pn 

K 

6 

P9 

Pb 

PP 

K 

7 

P9 

pb 

PP 

K 

8 

n 

Dl 

Pi- 

■Dn  pn 

K 

9 

n 

*1 

Yi., 

.  .  Xn  Yn 

K  12  m  P-\  . . .  Pm 
K  13  n  m  N 


vsn  •• 

•vsn1 

M^ 

VR1  . 

E 

cc 

> 

pn 

# 

VRt  . 

E 

cc 

> 

^•,1 

vs1N . 

•  ■  vsnN 

mn 

VR.,  . 

< 

3D 

3 

P1N 

VR,  . 

< 

30 

3 

pM„l 

n  :  Number  of  inputs;  0<n<10 
m  :  Number  of  outputs;  1<m<10 

N  :  Number  of  output  sets, 

(if  n=0,  N=1 );  1<N<10 

Mj  :  Number  of  output  terms  for  the 
i*^1  output  set;  1  <  M j  <  1 0 
K  14  n  a-|  . . .  an  aQ 
K  15  V,  V2  V3  V4  P,  P2 

K:  KIND  NUMBER 
P:  PROBABILITY 
V:  VALUE 
D:  DELAY 

SEE  THE  GO  REFERENCE  MANUAL 
FOR  COMPLETE  DESCRIPTION  OF 
INPUT  DATA _ 

FIGURE  14  G02  KIND  DATA 
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If  we  refer  to  the  GO  model  of  the  example  system  (Figure  10)  the 
probability  data  for  the  plug,  shown  as  a  type  1  kind  10  operator  in  Figure 
10,  might  be  as  follows: 

10  1  0.9  0.1  $  PLUG 

This  indicates  that  kind  10  is  referenced  by  a  type  1  operator.  That 
operator  has  a  success  probability  of  0.9  and  a  failure  probability  of  0.1. 
The  dollar  sign  ($)  is  again  a  data  terminator  and  optional  descriptive 
information  about  the  data  can  be  placed  to  the  right  of  the  terminator. 

The  probability  data  needed  for  a  specific  GO  model  must  be  developed  by 
the  analyst.  This  will  usually  be  done  by  referencing  a  data  base  or  by 
engineering  judgement. 

The  analyst  must  insure  that  the  data  being  used  is  appropriate.  For 
example  there  are  three  types  of  data  which  are  often  used  for  system 
analyses.  These  are  (1)  per  demand  probability  estimates,  (2)  reliability 
with  time  estimates,  and  (3)  availability  estimates. 

Per  demand  or  startup  estimates  are  derived  from  binomial  trials.  Given, 
from  experience,  that  there  have  been  x  successful  starts  in  n  trials  the 
reliability  point  estimate,  R,  for  successful  startup  is  given  as  the 

x  Xi  h 
expected  value  ■■  -,  hence  R.  =  — - —  for  the  i  component.  An  un- 

i 

biased  estimate  for  the  variance,  V,  of  the  reliability  is  also  provided  by 
the  expressions, 

— ) 

n  /  x(n-x) 

3 
n 

This  variance  estimate  permits  the  treatment  of  uncertainty  in  system 
estimates  as  a  function  of  uncertainties  in  component  estimates,  but  is,  of 
course,  invalid  if  x=0  or  x=n.  If  either  of  these  cases  occur  arbitrary 
variance  estimates  must  be  generated  by  some  other  means. 

The  reliability  with  time  estimates  are  generated  using:  ^available  failure 
rate  data.  Using  X^  as  the  failure  rate  for  the  i  component,  the 
reliability,  R_^,  of  that  component  at  time  t  is. 


This  is  the  probability  that  the  component  has  not  failed  since  being  placed 
in  service  up  to  time  t.  The  formulation  presumes,  that  the  failure  rates 
are  constant  and  therefore  that  the  time-to-failure  distributions  are 
exponential.  (Other  time-to-failure  distributions  could  be  used,  e.g., 
uniform,  lognormal,  normal,  gamma,  Weibull,  etc.) 
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Availability  estimates  for  a  system  can  be  generated  from  component 
availability  point  estimates  using  GO  models.  The  system  availability 
estimate,  A,  is  a  function  o£^  the  component  availability  estimates. 
These  are  denoted  as  A^  for  the  i  component.  Hence, 

A  =  f (A  ,  A  ,  ...»  A  ) . 

1  z  n 

The  component  availability  point  estimates  can  be  derived  using  the  well 
established  function, 


MTTFi 

Ai  MTTF.  +  MTTR. 

1  1 


where,  ^ 

A.  =  Availability  point  estimate  of.  the  i  component, 

MTTF^  =  Mean-Time-To-Failure  of  the  ^  component, 

MTTR_  =  Mean-Time-To-Repair  of  the  i  component. 

If  the  times-to-failures  are  exponentially  distributed,  then 

1  t  h 

MTTF.  =  — where  A.  is  the  failure  rate  of  the  i  component. 

l  A .  l 

l 

Since  several  sources  exist  containing  published  generic  failure  rate  data  for 
most  components,  representative  estimates  for  MTTF.  are  available  for  most 
types  of  components.  Less  data  is  available  to  establish  representative 
estimates  for  the  MTTR.  These  estimates  are  functions  of  the  general 
maintenance  philosophy  -  frequency  of  test,  training,  stock  levels,  etc. 
Where  component  MTTF  and  MTTR  data  are  not  available  for  modeled  components, 
engineering  estimates  can  be  made  of  their  availabilities. 

The  actual  G02  data  entered  for  the  example  system  is  recorded  in  the 
following  seven  lines. 

GO 2  DATA  FOR  EXAMPLE  SYSTEM 
$PARAM  $ 

10  1  0.9  0.1  $  PLUG 

11  1  0.7  0.3  $  MOTOR 

50  5  1  1  1.  $  ELECTRIC  POWER 

51  5  1  2  1.  $  SAM 

60  6  0.8  0.2  0.0  $  SWITCH 

As  in  program  G01,  the  data  for  program  G02  commences  with  a  model  name 
or  header  line  entry.  The  second  entry  is  again  a  Fortran  namelist  parameter 
called  PARAM  which  permits  the  setting  of  the  parameter  PERFECT.  In  this  case 
the  parameter  PERFECT  was  left  at  its  default  value. 

The  next  five  lines  of  data  record  the  kind  numbers  associated  operator 
types,  and  the  probability  data  for  each  component.  The  first  two  entries  on 
each  line  are  the  kind  and  type.  The  remaining  entries  are  the  required 
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probabilities  and  other  data  necessary  to  define  the  probabilistic  operation 
of  a  particular  operator  type.  (Refer  to  Figure  14  which  shows  the  format  of 
the  data  entries  for  each  operator  type.) 

In  this  model  kinds  10  and  11  are  referenced  by  type  1  operators,  kinds 
50  and  51  by  type  5  operators,  and  kind  60  by  a  type  6  operator.  The  G02  data 
for  the  type  1  operators  records  the  success  and  failure  probabilities  of 
operation.  The  G02  data  for  the  type  5  operators  indicates  that  in  each  case 
there  is  only  one  value  which  is  taken  with  certainty.  Electric  power  is 
available  at  time  1  with  certainty,  and  Sam  throws  the  switch  at  time  2  with 
certainty.  The  G02  data  for  kind  60  type  6  contains  the  success,  failure,  and 
premature  probabilities  of  operation.  In  this  case  the  premature  probability 
is  specified  to  be  0.0. 

GO  Execution 

To  execute  the  GO  sequence  three  computer  programs  in  the  set  of  GO  codes 
are  called  upon  to  process  the  model  data.  These  are  programs  G01,  G02  and 
G03.  Program  G01  processes  the  operator  data  which  defines  the  system 
structure.  Program  G02  processes  the  probability  data  insuring  its  internal 
consistency  and  proper  reference  from  operators  processed  in  G01.  Program  G03 
executes  the  operators  in  the  GOl  data  and  introduces  the  probability  data 
from  G02  to  generate  the  event  tree  for  the  specific  model  being  processed. 

To  portray  how  this  is  done  representative  data  for  the  example  system  of 
Figures  9  and  10  have  been  recorded  in  Figure  15. 

Note  that  the  data  is  separated  into  three  sets  —  one  for  each  of  the 
three  GO  programs  to  be  executed,  GOl,  G02,  and  G03.  We  have  previously 
discussed  the  data  for  programs  GOl  and  G02 .  In  each  set  there  is  a  name  or 
header  card,  and  a  parameter  card.  The  parameter  card  for  GOl  defines  INFIN=3 
which  tells  the  computer  that  the  largest  value  which  the  random  variables  may 
take  in  this  analysis  is  3.  Consequently  the  permissible  values  will  be  0,  1, 
2,  and  3,  with  the  associated  meanings  previously  defined.  The  subsequent 
data  in  GOl  defines  the  operators  and  associates  their  inputs  and  outputs. 
The  final  card  commencing  with  a  0  entry  flags  the  computer  that  this  is  the 
end  of  the  GOl  data  and  that  signal  5  is  to  be  the  output  signal  whose  mass 
density  function  is  to  be  displayed. 

The  G02  data  reflects  the  probabilities  which  were  assigned  for  this 
analysis.  Note  that  both  the  availability  of  electric  power  and  Samfs  action 
are  perfect  but  that  they  occur  at  time  1  and  time  2  respectively.  That  is, 
power  is  certain  to  be  available  at  time  1  and  Sam  is  certain  to  actuate  the 
switch  at  time  2. 

In  G03  the  parameter  PMIN  which  could  permit  truncation  of  low 
probability  events  is  set  to  0.0.  Consequently,  no  pruning  will  occur. 
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G01  DATA  FOR  EXAMPLE  SYSTEM 
$PARAM  INFIN=3  $ 

5  50  1  $  ELECTRIC  POWER 
1  10  1  2  $  PLUG  &  CORD 

5  51  3  $  SAM 

6  60  2  3  4  $  SWITCH 

I  11  4  5  $  MOTOR 

0  5  $  FINAL  OUTPUT  SIGNAL 
EOR* 

G02  DATA  FOR  EXAMPLE  SYSTEM 
$PARAM  $ 

10  1  0.9  0.1  $  PLUG 

II  1  0.7  0.3  $  MOTOR 

50  5  1  1  1.  $  ELECTRIC  POWER 

51  5  1  2  1.  $  SAM 

60  6  0.8  0.2  0.0  $  SWITCH 
EOR 

G03  DATA  FOR  EXAMPLE  SYSTEM 
$PARAM  PMIN=0. 0  $ 

EOR 

EOF _ 

FIGURE  15  GO  DATA  FOR  EXAMPLE  SYSTEM 


An  event  tree  for  this  example  system  can  be  easily  created.  Such  a  tree 
is  shown  in  Figure  16.  Moving  from  left  to  right  the  branches  in  the  tree  are 
depicted  in  the  order  in  which  the  operators  were  introduced  in  the  G01  data. 
The  plug,  switch,  and  motor  states  were  represented  by  P,  S,  and  M 
respectively  subscripted  with  g,  for  good,  and  f,  for  failed.  Events  are  also 
shown  using  the  subscripted  signal  numbers. 

Note  that  only  one  branch  of  the  tree  leads  to  a  system  success.  This  is 
event  5 ^  defined  as  successful  motor  operation  when  Sam  turns  on  the  switch. 
All  other  branches  lead  to  motor  failure  because  of  plug  switch  and  motor 
failure. 

The  event  tree  which  is  actually  created  by  G03  is  slightly  different 
than  that  of  Figure  16.  The  difference  is  that  after  each  operator  is 
processed  all  identical  events  are  combined.  This  reduces  the  number  of 
branches  and  results  in  more  efficient  processing.  Figure  17  portrays  how 
this  branch  combination  process  is  employed  for  the  example  system  to  generate 
the  two  final  output  events,  5^  and  5^. 

If  more  visibility  about  other  combinations  of  the  signals  is  desired  we 
could  specify  them  as  final  output  signals.  If  every  signal  were  specified  as 
a  final  output  signal  the  tree  of  Figure  18  would  be  generated.  In  this  case 
there  are  four  final  events,  representing  the  four  unique  combinations  of  the 
random  variables.  As  before  identical  events  generated  are  combined  reducing 
the  number  of  branches  in  the  tree. 


*  EOR  and  EOF  mean  End-of-Record  and  End-of-File  respectively.  Different 
computers  use  different  nomenclature  for  these  expressions. 
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FIGURE  16  EVENT  TREE  FOR  EXAMPLE  SYSTEM 


25 


FIGURE  17  GO  EVENT  TREE  FOR 
EXAMPLE  SYSTEM  WITH  SIGNAL  5  AS  THE  ONLY  OUTPUT 
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FIGURE  18  GO  EVENT  TREE  FOR  EXAMPLE  SYSTEM 
WITH  ALL  SIGNALS  AS  OUTPUTS 


GO  Results 


In  most  GO  analyses  the  event  trees  are  not  depicted.  Usually,  only  the 
final  branches  of  the  tree  are  retained  and  recorded  because  they  provide  the 
information  about  system  performance  which  the  model  was  created  to  generate. 
Internal  information,  while  optionally  available,  is  almost  always  suppressed 
to  eliminate  voluminous  output. 

The  results  of  a  GO  analysis  include  the  list  of  all  possible  system 
event  states  and  their  probabilities  of  occurrence.  The  G03  output  for  the 
example  system  previously  discussed  is  shown  in  Figure  19. 

In  Figure  19  the  final  event  table  records  the  resultant  branches  of  the 
event  tree  of  Figure  17.  Signal  5  was  the  only  output  signal  specified.  As 
shown  in  Figure  19,  signal  5  can  take  two 


FINAL  EVENT  TABLE  (INFINITY  =  3) 

SIGNALS  AND  THEIR  VALUES 


PROBABILITY  5 


0.4960000000  3 

0.5040000000  2 


TOTAL  PROBABILITY  =  1.0000000000 
TOTAL  ERROR  = _ .0000000000 _ 

FIGURE  19  G03  RESULTS  FOR  EXAMPLE  SYSTEM 


values,  2  and  3.  The  probability  that  signal  5  takes  value  2  (the  system 
success  event)  is  0.504.  The  probability  that  signal  5  takes  value  3  (the 
system  failure  event)  is  0.496  for  this  system.  Note  also  that  because  no 
terms  were  discarded  (no  branches  pruned)  there  is  zero  calculat ional  error. 

A  second  execution  of  this  model  was  made  specifying  all  of  the  random 
variables  as  final  output  signals.  This  was  done  by  altering  the  last  G01 
data  entry  to  read: 

0  1  2  3  4  5  $  FINAL  OUTPUT  SIGNALS 

The  results  from  this  run  are  shown  in  Figure  20.  We  have  now  generated  the 
complete  joint  distribution  of  the  five  random  variables  generating  four 
unique  events.  These  are:  1^  ^y>2^y>2>9  1 12 132^3^3 >  and 

LWzV 

In  addition  to  the  complete  joint  distribution  generated  by  the  computer 
program,  the  code  also  produces  the  marginal  distribution  for  each  individual 
signal.  (A  marginal  distribution  is  outlined  by  adding  the  probabilities  of 
occurrence  of  a  single  signal  taking  a  specific  value  without  regard  to  the 
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values  taken  by  other  signals  in  the  joint  events.)  Consequently,  as  in  the 
prior  case,  we  see  that  signal  5  can  take  only  the  values  2  and  3  with  the 
probabilities  previously  noted.  Also  note  that  signals  1  and  3  only  take  a 
specific  value  with  certainty  because  this  is  the  way  we  specified  the  input 
data. 


FINAL  EVENT 

TABLE 

(INFINITY  = 

3) 

SIGNALS  AND  THEIR  VALUES 

PROBABILITY 

1 

2  3 

4 

5 

. 1000000000 

1 

3  2 

3 

3 

. 1800000000 

1 

1  2 

3 

3 

.2160000000 

1 

1  2 

2 

3 

.5040000000 

1 

1  2 

2 

2 

TOTAL  PROBABILITY 

=  1.0000000000 

TOTAL  ERROR 

= 

.0000000000 

INDIVIDUAL  ! 

SIGNAL 

PROBABILITY  DISTRIBUTIONS 

VAL. 

1 

2 

3 

4 

5 

1  1.0000000000 

.9000000000  0 

.0000000000 

0.0000000000 

0.0000000000 

2  0.0000000000 

0.0000000000  1 

.0000000000 

.7200000000 

.5040000000 

3  0.0000000000 

.1000000000  0 

.0000000000 

.2800000000 

.4960000000 

EXECUTION  TIME  = 

.14  SECONDS. 

FIGURE  20  FINAL  EVENT  TABLE  FOR  EXAMPLE  SYSTEM 
WITH  ALL  SIGNALS  AS  FINAL  OUTPUTS 


GO  Symbols 

In  the  prior  sections  of  this  chapter  most  of  the  symbols  employed  in  the 
GO  methodology  have  been  introduced.  In  this  section  we  summarize  the 
conventions  which  have  evolved. 

The  logical  operator  types  without  inputs  (types  4  and  5)  are  represented 
in  a  GO  model  using  triangles.  All  other  operator  types  are  represented  with 
circles.  Inside  either  the  triangle  or  the  circle  representing  a  system 
element  is  written  a  hyphenated  type-kind  number  identifying  the  logical  type 
of  the  operator  and  the  associated  probabilities  referenced  by  the  kind 
number . 

Model  elements  are  connected  by  arrows  showing  the  direction  of  flow. 
These  arrows  or  lines  are  all  numbered  to  identify  the  input  and  output 
signals  to  the  operators.  Half  arrows  are  used  to  identify  the  second  input 
for  operators  requiring  two  inputs  where  signal  order  is  important. 

Numbers  are  used  as  identifiers  for  each  of  the  15  logical  operator 
types ,  as  arbitrary  kinds  to  reference  probabilities,  as  signal  numbers 
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specifying  the  random  variables,  and  as  the  small  set  of  defined  values  which 
the  random  numbers  may  take.  In  addition,  not  previously  discussed,  the 
operators  are  numbered  by  the  sequence  in  which  they  are  executed  as  listed  in 
the  G01  data  to  generate  an  operator  number  for  each. 

Events  are  specified  by  signal  numbers  subscripted  with  specific  values. 
Joint  events  involving  two  or  more  random  variables  are  identified  by  a  string 
of  such  subscripted  signal  numbers.  For  example,  the  representation  8  12 
means  the  event  that  signal  8  takes  value  1  and  signal  12  takes  value  3.  1  3 

GO  Terminology 

To  express  ideas  and  concepts  precisely  a  vocabulary  of  GO  terminology 
has  developed.  A  number  of  words  have  been  given  specific  meanings. 
Experience  has  shown  that  these  definitions  permit  consistent,  unambiguous 
exposition  of  the  procedure. 

Thirty-three  of  the  terms  defined  to  enhance  understanding  about  and  use 
of  the  GO  methodology  are  listed  in  Figure  21.  A  brief  definition  of  each 
term  is  provided.  A  number  of  the  terms  have  not  been  used  in  our  exposition 
to  this  point.  They  await  a  full  development  in  companion  manuals  for  the 
more  serious  student  and  user  of  the  GO  methodology. 

GO  Supertypes 

To  conclude  this  brief  exposition  of  the  GO  methodology  we  mention  one 
additional  feature,  that  of  GO  supertypes.  A  supertype  is  simply  a  defined 
collection  of  elemental  GO  operators  which  is  treated  as  an  entity  and  which 
may  be  called  up  one  or  more  times  in  a  GO  model.  Supertypes  are  used  to 
reduce  the  complexity  of  a  model  (like  a  block  diagram  approach)  or  to 
eliminate  the  need  to  remodel  identical  configurations. 

A  supertype  is  defined  using  an  identification  number  greater  than  or 
equal  to  100.  A  flag  of  -1  or  0  is  used  to  inform  the  computer  whether  this 
is  a  definition  or  a  use  of  the  supertype.  The  dummy  input  signal  numbers  in 
the  supertype  definition  are  allocated  to  the  range  100-199.  Dummy  output 
signal  numbers  are  allocated  the  range  200-299.  Dummy  kind  numbers  which  can 
be  used  to  permit  different  probabilities  of  operation  for  logically 
equivalent  configurations  must  exceed  999. 

To  illustrate  the  concept  consider  the  schematic  of  Figure  22. 


FIGURE  22  EXAMPLE  SCHEMATIC 
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FiGURE  21  GO  TERMINOLOGY 


The  system  consists  of  a  battery,  two  switches,  and  two  lights.  Assume  that 
the  battery  is  connected  to  the  circuit  at  a  certain  time,  a  little  later  SI 
is  actuated,  and  even  later  S2  is  actuated  (we  will  designate  these  times  by 
the  numbers  1,  2,  and  3  respectively).  Assume  that  our  interest  is  in  the 
time  at  which  at  least  one  light  comes  on. 

In  creating  a  GO  model  for  this  system  we  observe  that  there  are  two 
redundant  switch-light  trains.  Consequently  a  supertype  modeling  one  train 
can  be  defined  once  and  called  up  twice,  once  for  each  train.  Let  us  call 
this  supertype  100. 

The  G01  data  for  our  GO  model  of  this  schematic  could  be  written  as 
follows : 


G01 

DATA  FOR  EXAMPLE  SCHEMATIC 

$PARAM  INFIN=4  $ 

100 

- 

1 

101  102  201  $  SUPERTYPE 

100  DEFINITION 

6  4 

101 

102  1  $  SWITCH 

1  5 

1 

201  $  LIGHT 

END* 

5  1 

1 

$ 

BATTERY  INSTALLATION 

1  2 

1 

2 

$  BATTERY 

5  3 

3 

$ 

SAM 

100 

0 

2 

3  5  $  TOP  SWITCH-LIGHT 

CHANNEL 

5  4 

4 

$ 

JOE 

100 

0 

2 

4  6  $  BOTTOM  SWITCH-LIGHT  CHANNEL 

2  0 

2 

5 

6  7  $  OR  GATE 

0  7 

$ 

FINAL  SIGNAL 

EOR 

FIGURE  23  EXAMPLE  SUPERTYPE  DEFINITION  AND  USE 


Note  that  the  first  instructions  in  G01  define  the  switch-light  supertype 
as  supertype  100  with  dummy  inputs  101  and  102  and  dummy  output  201.  Signal 
101  represents  the  electrical  input  from  the  battery  and  signal  102  represents 
the  mechanical  switch  action  by  either  Sam  or  Joe.  Signal  201  represents  the 
light  output.  No  dummy  kind  numbers  permitting  variable  kinds  were  defined 
for  this  example. 

After  the  supertype  is  defined  the  G01  model  data  is  entered.  Note  the 
two  calls  of  supertype  100  and  the  final  OR  combination  of  the  supertype 
outputs  defining  system  operation. 

In  drawing  GO  models  using  supertypes  we  have  adopted  the  convention  of 
using  rectangles  to  represent  them.  An  important  consideration  is  to  insure 
that  the  proper  signals  replace  the  dummy  parameters  in  the  uses  of  the 
supertypes.  That  is,  to  insure  accurate  model  representation,  the  supertype 
must  be  "hooked  up"  properly. 


*  A  supertype  definition  is  terminated  by  any  word  string  beginning  with  E, 
e.g.,  END,  EUREKA. 
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The  GO  model  for  this  example  schematic  is  shown  as  follows: 


USING  SUPERTYPES 


We  will  not  pursue  the  supertype  example  further  except  to  say  that  it  is 
a  very  useful  device  when  redundant  or  replicated  models  are  created.  The 
computer  actually  generates  multiple  unique  sets  of  random  variables  for  each 
supertype  use.  Consequently,  the  use  of  supertypes  saves  analyst  labor  but 
not  computer  processing  time. 
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CHAPTER  4 
EXAMPLES 


This  chapter  portrays  in  detail  the  development  of  GO  models  of  seven 
systems  ranging  from  simple  to  relatively  complex.  The  first  example  of  a 
series  system  of  two  components  is  trivial  and  the  system  can  be  analyzed  by 
hand  in  a  few  seconds.  Nevertheless,  the  development  of  a  GO  model  and  the 
explanation  and  interpretation  of  the  input  data  files  and  output  printout  for 
such  an  obvious  system  helps  the  reader  grasp  the  mechanics  of  using  the  GO 
software.  This  example  also  addresses  the  objective  of  an  assessment  and  the 
different  types  of  data  which  can  be  utilized  to  generate  system  reliability, 
reliability  with  time,  and  availability  estimates. 

Example  2  treats  a  similar  simple  system  composed  of  two  components  in 
parallel. 

Example  3  explores  the  treatment  of  statistical  dependencies  in  a  GO 
model  and  conclusively  demonstrates  that  the  GO  method  properly  accounts  for 
such  dependencies. 

In  each  of  these  first  three  examples  the  probability  trees  which  are 
generated  by  the  GO  software  are  explicitly  shown.  Most  of  the  time  the 
trees,  while  optionally  available  in  table  form,  are  not  visible. 

Example  4  is  a  somewhat  more  complex  alarm  system.  It  introduces  the  use 
of  three  values  (time  points)  to  represent  system  and  component  premature, 
success,  and  failure  operational  states.  It  also  exemplifies  the  use  of 
super types.  (The  alarm  system  example  is  addressed  again  in  Chapter  5  when 
fault  sets  are  treated.) 

Example  5  portrays  a  comparison  of  the  performance  of  a  two -out -of -two 
pump  train  system  with  that  of  a  two-out-of-three  pump  train  system.  The 
system  is  designed  to  continuously  pump  a  specified  amount  of  fluid  at  a  given 
pressure.  The  advantage  of  introducing  a  third  pump  train  is  addressed. 

The  most  complex  example  is  that  of  a  weapon  fuzing  system,  example  6. 
The  development  of  the  GO  model  for  this  system  takes  only  a  couple  hours.  To 
analyze  the  system  by  hand  or  by  other  methods  would  require  several  man  weeks 
or  months  of  effort.  Sixteen  time  points  are  used  to  characterize  the  safety 
and  reliability  of  the  weapon  fuzing  system.  A  supertype  for  a  parallel  pair 
of  normally  open  switch  contacts  is  used  repeatedly  to  model  the  dual-channel 
cross-connected  system. 

The  last  example  system  analyzed,  example  7,  is  that  of  a  simple 
communication  network.  The  probability  of  information  flow  from  one  node  to 
another  is  calculated  using  a  representative  GO  model.  Possible  two-way 
information  flows  on  some  links  are  modeled. 

These  examples  provide  a  significant  introduction  to  the  range  and 
application  of  the  GO  methodology  and  the  specifics  of  generating  data  and 
interpreting  the  computer  results. 
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Example  1  -  Two  Components  In  Series 


The  purpose  of  this  example  is  to  introduce  the  reader  to  the  manner  of 
developing  a  GO  model,  writing  the  GO  input  data,  and  interpreting  the  output 
data  using  a  trivial  example.  Having  introduced  the  reader  to  the  GO  process, 
the  model  is  executed  with  three  different  types  of  data  —  binomial  attribute 
data,  reliability  with  time  data,  and  availability  data  to  generate  different 
system  performance  measures.  The  event  tree  for  the  model  as  developed  by  the 
GO  software  is  shown.  To  conclude  the  example,  alternate,  but  equivalent, 
ways  of  developing  the  system  GO  model  are  portrayed. 


Consider  the  configuration  of  a  system  comprised  of  two  components  in 
series  as  depicted  in  Figure  25.  Obviously  both  components  must  function  for 
the  system  to  function. 


FIGURE  25 

SERIES  SYSTEM  OF  TWO  COMPONENTS 

Consequently,  we  can  write  the  equation  for  the  reliability  of  this  system  by 
inspection.  It  is  a  function  of  the  reliability  of  each  component.  If  r 
represents  the  reliability  of  component  A,  r^  that  of  component  B,  and 
r^  that  of  the  system,  then 


rs 


(1) 


Similarly,  we  can  write  the  equation  for  the  availability  of  this  system.  If 
a^  represents  the  availability  of  component  A,  a^  that  of  component  B, 
and  ag  that  of  the  system,  then 


a 

s 


(2) 


We  will  use  these  "obvious"  equations  later  to  compare  the  system 
reliability  and  availability  with  the  results  obtained  from  several  GO  models. 
We  now  develop  a  GO  model  of  this  system  which  we  will  subsequently  execute 
with  three  different  types  of  data.  Our  objective  in  each  case  will  be  to 
quantitatively  determine  the  reliability  or  the  availability  of  the  system. 


In  Figure  26  we  have  a  representation  of  this  system  using  standardized 
GO  operators  and  symbols. 
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SYSTEM  OF  TWO  COMPONENTS 

In  this  model  we  have  used  a  type  5  operator  which  requires  no  inputs  and 
produces  one  output  to  represent  component  A.  The  output  signal  generated  is 
called  signal  #3 .  It  becomes  the  input  to  component  B  which  is  modeled  as  a 
type  1  operator  which  has  one  input  signal,  signal  #3,  and  one  output  signal, 
signal  #8.  Signal  #8  is  the  output  signal  of  interest  for  this  system  model. 
(The  numbering  of  the  signals  is  completely  arbitrary  in  the  range  1-1500,  but 
signal  numbers  must  be  unique.) 

Initially  we  will  permit  the  signals  (random  variables)  to  take  values  of 
0  or  1.  A  value  of  0  will  mean  successful  —  reliable  or  available  —  and  a 
value  of  1  will  mean  failure  —  unreliable  or  unavailable.  Consequently, 
the  event  8 ,  signal  8  takes  value  0,  represents  system  success.  The  event 
8^,  signal  ft  takes  value  1,  represents  system  failure. 

The  probabilities  associated  with  the  operational  state  of  the  two 
components,  A  and  B,  are  referenced  by  the  kind  numbers  11  and  12 
respectively.  (The  kind  numbers  selected  are  again  completely  arbitrary  in 
the  range  1-200. ) 

As  a  first  case  the  reliabilities  of  the  two  components  have  been 
obtained  by  testing  samples  of  components  from  the  populations  of  components 
from  which  A  and  B  have  been  randomly  selected  to  fabricate  the  system. 
For  component  A,  33  like  components  were  tested,  31  were  reliable.  For 
component  B,  74  have  been  tested  and  all  but  one  were  found  to  be 
successful. 

Consequently,  the  reliabilities  for  components  A  and  B  are  the 
proportions: 

rA  =  =  0.9394,  r  =  =  0.9865. 

33  B  74 

To  use  the  KSC  GO  software  to  calculate  the  reliability  of  this  system, 
three  data  records,  one  for  each  of  the  three  GO  programs,  G01,  G02,  and  G03, 
are  prepared.  The  data  record  for  G01  communicates  the  logical  structure  of 
the  system  —  its  configuration  defining  components  and  their  interactions  — 
to  the  computer.  The  data  record  for  G02  communicates  the  point  estimate 
probabilities  associated  with  each  model  element.  The  data  record  for  G03 
communicates  information  influencing  the  manner  in  which  the  probability  tree 
for  the  system  will  be  created. 

Figure  27  records  the  three  data  files  for  this  system.  The  records  are 
separated  with  "EOR"  which  means  End  of  Record. 
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G01  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
$PARAM  INFIN=1$ 

5  11  3  $  COMPONENT  A 

I  12  3  8  $  COMPONENT  B 

0  8  $  FINAL  SIGNAL 

EOR 

G02  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
$PARAM  $ 

II  5  2  0  0.9394  1  0.0606  $  COMPONENT  A 

12  1  0.9865  0.0135  $  COMPONENT  B 

EOR 

G03  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
$PARAM  PMIN=0 . 0  $ 

EOR _ 

FIGURE  27  GO  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 

In  each  record  the  first  line  entry  records  the  name  or  title  given  the 
record  and  the  second  line  entry  calls  up  a  Fortran  namelist  parameter  called 
PARAM  which  allows  the  user  to  set  selected  parameter  values.  In  G01  the 
parameter  INF IN  was  set  to  1,  permitting  the  signals  to  take  the  values  0  and 
1.  Consequently,  in  this  model,  1  is  the  largest  permissible  value.  In  G02 
no  parameters  were  changed  so  default  values  were  used.  In  G03  parameter  PMIN 
was  set  to  0.  Consequently,  no  terms  will  be  discarded  or  pruned. 

In  the  G01  data  record  we  next  introduced  the  data  line  M5  11  3  $ 
COMPONENT  A".  This  tells  the  computer  that  the  first  operator  is  a  type  5 
operator  with  kind  11,  probabilities  generating  signal  #3.  The  $  (dollar 
sign)  terminates  the  entry  and  we  can  further  identify  the  model  element  with 
descriptive  information  to  the  right  of  the  terminator.  Next,  the  information 
for  component  B  is  entered.  Component  B  has  been  modeled  as  a  type  1,  kind 
12,  operator  with  input  signal  #3  and  output  signal  #8.  The  last  entry  "0  8  $ 
FINAL  SIGNAL"  terminates  the  G01  data  input.  The  0  is  a  flag  indicating  no 
additional  operators  are  to  be  specified.  The  subsequent  entries  on  the  data 
line  initialized  with  a  0  tell  the  computer  the  final  signals  to  be  included 
in  the  output  data  and  the  order  in  which  they  will  occur  in  the  output  joint 
distribution.  In  this  case  only  the  single  signal,  #8,  is  specified. 

The  G01  software  recognizes  the  nature  of  the  data  which  must  be  entered 
for  each  logical  operator  type.  (See  Figure  11,  G01  Operator  Data,  in  Section 
3.)  Diagnostics  are  provided  if  the  user  fails  to  provide  the  requisite 
amount  of  data  or  if  the  data  supplied  is  inconsistent. 

The  G02  data  record  consists  of  a  name  line  and  a  parameter  line  followed 
by  two  line  entries  recording  the  probability  data  for  kinds  11  and  12.  The 
line  entry  "11  5  2  0  0.9394  1  0.0606  $  COMPONENT  A"  records  that  kind  11  is 
used  by  a  type  5  operator  which  generates  a  signal  taking  2  values.  These 
values  are  0  which  is  taken  with  probability  0.9394  and  1  which  is  taken  with 
probability  0.0606.  These  probabilities,  specifying  the  probabilities  with 
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which  the  possible  values  are  taken,  must  sum  to  1.0.  The  dollar  signal  ($) 
is  again  a  terminator  to  the  right  of  which  descriptive  information  may  be 
written. 

The  line  entry  for  kind  12  reads  "12  1  0.9865  0.0135  $  COMPONENT  B" .  It 
specifies  that  kind  12  data  is  used  by  a  type  1  operator.  A  type  1  operator 
requires  two  probabilities  —  the  first  for  the  success  mode  and  the  second 
for  the  failure  mode.  These  again  must  sum  to  1.0. 

The  G02  software  recognizes  the  nature  of  the  probability  data  which  must 
be  entered  for  each  logical  operator  type.  (See  Figure  14,  G02  Kind  Data,  in 
Section  3.)  Diagnostics  are  provided  if  the  user  fails  to  provide  the 
requisite  amount  data  or  if  the  data  supplied  is  inconsistent. 

The  G03  data  record  for  this  model  consists  of  only  two  data  lines,  the 
name,  and  the  parameter,  entries. 

The  output  files  from  executing  the  G01 ,  G02,  and  G03  software  using  the 
input  data  of  Figure  27  are  shown  in  Figures  28,  29,  and  30. 

Figure  28  portrays  the  output  file  for  G01  for  the  Series  System  of  Two 
Components  defined  by  the  data  described  above.  The  output  records  the  date 
on,  and  time  at,  which  this  run  was  executed  and  notes  the  software  version 
being  used.  It  then  records  the  name  of  the  model  as  noted  in  the  G01  name 
line  entry.  Next  the  values  of  the  various  parameters  are  recorded.  We  set 
INFIN  equal  to  1.  Default  values  were  used  for  other  parameters.  (These  are 
defined  and  explained  in  the  KSC  GO  Reference  Manual.) 

The  operator  data  furnished  is  recorded  and  each  operator  is  numbered. 
The  software  then  provides  a  cross-reference  index  documenting  where  signals 
are  created  and  where  they  are  used.  For  example,  in  this  model  signal  #3  was 
generated  by  operator  number  1  which  is  a  type  5,  kind  11  operator.  Signal  #3 
is  used  in  operator  number  2  and,  since  it  is  not  specified  as  a  final  output 
signal  and  is  no  longer  needed  as  an  input  to  any  other  operator,  it  is 
deleted  from  further  consideration. 

The  next  set  of  information  on  the  G01  printout,  Figure  28,  registers  the 
number  of  active  signals  in  the  distribution  after  each  operator  has  been 
executed.  The  entry  1(1)  means  that  after  operator  1  has  executed,  there  is 
only  one  signal  in  the  distribution.  Reference  to  the  GO  model  of  Figure 
26  or  to  the  data  for  operator  number  1  shows  that  this  is  signal  #3.  After 
the  second  operator  has  executed,  there  is  again  only  one  signal  in  the 
distribution.  This  time  it  is  signal  #8. 

Some  additional  information  about  the  model  is  then  recorded,  e.g., 
numbers  of  operators,  signals,  etc.  Then  the  final  signals  which  will  appear 
in  the  output  distribution  are  noted  (in  this  case  only  signal  #8  will 
appear) . 
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<301  ( KSCGO »  VAX  VERSION  1.0)  RUN  ON  20-0CT-S2  AT  10:T3!54 

COPYRIGHT  (C)  1982  by  KAMAN  SCIENCES  CORPORA! ION 


GDI  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
INFIN  -  1 7  VALUES  ~  2?  BIAS  “  750»  OPS  - 

OP  DATA 


1?  SIGNALS  "  1? 
ERRORS  ~  25 


1  5  11  3  $  COMPONENT  A 

2  1  1238$  COMPONENT  B 

/ / / 3  0  8  $  FINAL  SIGNAL 

SIGNAL  DATA 

SOURCE  OPER . 

SIGNAL  HUM  TYPE  KIND  USING  OPERATORS  (-  IF  DELETED  AT) 


3  1  5  11  -2 

8  2  1  12 

OPERATOR ( NUMBER  OF  ACTIVE  SIGNALS) 
1  (  1 )  2  (  1  ) 


NUMBER  OF  OPERATORS..,  -  2 

NUMBER  OF  SIGNALS .  -  2 

MAXIMUM  NUMBER  ACTIVE,  ~  1 

MAX  SIGNAL  LIST  SIZE..  -  1 

NUMBER  OF  SIGNALS/WORD  *  32 

MAXIMUM  WORDS/TERM....  «  1 


FINAL  SIGNALS  =  8 

CPU  TIME  =  0:00:00.39 
DIRECT  I/O  COUNT  «  5 
ELAPSED  TIME  =  00  :  00*.  01. 37 


FIGURE  28 


G01  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
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GQ2  (KSCGOr  VAX  VERSION  1.0)  RUN  ON  20-0CT-82  AT  10*.  43  *.56 
COPYRIGHT  (C)  1982  by  KAMAN  SCIENCES  CORPORATION 

G02  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 

PERF  -  0?  MXSIZE  -  2048 

OPERATOR  FILE  -  G01  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 

RECORD  KIND  DATA 


1  11  5  2  0  0.9394  1  0.0606  $  COMPONENT  A 

2  12  1  0.9865  0.0135  $  COMPONENT  B 

3  END 


USE  SUMMARY  TABLE.  ENTRY  ~  KIND/TYPE ( FREQUENCY ) 
(FREQUENCY  IS  NEGATIVE  FOR  PERFECT  KINDS.) 

11/  5(  1 )  12/  1 (  1  ) 

NUMBER  OF  KINDS  INPUT -  2 

NUMBER  USED  -  NONPERFECT--  2 

NUMBER  USED  -  PERFECT-- . .  0 

1  FILE  RECORDS  WRITTEN  FOR  2  OPERATORS. 

CPU  TIME  =  05 00 500.40 
DIRECT  I/O  COUNT  -  13 
ELAPSED  TIME  =  00500501.35 


FIGURE  29 

G02  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
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fi 0 3  ( KSCGO >  VAX  VERSION  1,0)  RUN  ON  20-0CT-82  AT  10  M3  1 58 

COPYRIGHT  (C)  1982  bu  KAMAN  SCIENCES  CORPORATION 

G 0 3  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 

OPERATOR  FILE  ---  G01  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
KIND  FILE G02  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 

RUN  NUMBER  1 

PMIN  =0 , OOOOE+OO 

NEW  --  0 1  INTER  =  0>  SAVE  -  0»  MXDIST  «  3000 

FIRST  ~  10000;  LAST  ~  10000;  TRACE  -  2.00000 


FINAL  EVENT  TABLE  (INFINITY  -  1) 

SIGNALS  AND  THEIR  VALUES 


PROBABILITY  8 

0,0732819000  1 

0.9267181000  0 


TOTAL  PROBABILITY  -  1,0000000000 

TOTAL  ERROR  •-  0.0000000000 


INDIVIDUAL  SIGNAL  PROBABILITY  DISTRIBUTIONS 

VAL.  8 

0  0.9267181000 

1  0.0732819000 


CPU  TIME  ~  0  too: 00. 36 
DIRECT  I/O  COUNT  -  7 
ELAPSED  TIME  ~  00  *.00  J00.69 


FIGURE  30 

G03  DATA  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 


40 


Finally  the  CPU  time  (central  processor  units),  direct  I/O  count  (number 
of  input/output  data  records  of  size  512  bytes  manipulated),  and  the  elapsed 
clock  time  required  to  execute  program  G01  for  this  model  are  recorded. 

The  G02  output  data  (Figure  29)  is  similar  to  that  of  G01.  The  date  and 
time  of  execution,  the  software  version  being  used,  the  name  of  the  model,  and 
the  parameter  values  are  all  recorded.  The  kind  data  is  then  listed  and  each 
entry  numbered.  A  use  summary  table  for  each  kind/type  is  provided  recording 
how  many  operators  referenced  each  set  of  kind  probabilities.  Some  additional 
details  about  the  data  are  provided,  then  the  CPU  time,  I/O  count,  and  elapsed 
time  for  program  G02  execution  are  recorded. 

The  G03  output  data  (Figure  30)  contains  the  results  from  executing  this 
series  system  of  two  components.  After  the  copyright  notice  indicating  the 
software  version  being  used,  the  title  of  this  system  as  entered  on  the  first 
line  of  G03  data  is  printed.  This  is  followed  by  an  identification  of  the 
operator  (G01)  and  kind  (G02)  files  used  as  input  to  G03.  Next  the  values  of 
the  parameters  used  in  G03  are  given.  With  the  exception  of  PMIN  which  was 
set  equal  to  0.0,  all  other  parameters  have  their  default  values.  (The 
meaning  and  purpose  of  these  additional  parameters  are  explained  in  the  GO 
Reference  Manual. ) 

In  Figure  30,  the  Final  Event  Table  lists  the  two  possible  events:  8  , 
the  system  success  event,  and  8  ,  the  system  failure  event.  The  probability 
of  success  (system  reliability)  is  0.9269181  and  that  of  failure,  0.0732819. 

In  this  execution  no  terms  were  discarded  so  there  is  no  computational 
error.  The  line  entry  "Total  Probability  =  1.0"  is  the  sum  of  the 
probabilities  of  occurrence  of  all  events.  Subtracting  that  sum  from  unity 
gives  zero  computational  error  due  to  pruning  for  this  execution. 

For  many  system  models  more  than  one  final  output  signal  will  be 
requested.  Consequently,  the  Final  Event  Table  will  contain  the  joint 
probability  distribution  of  all  such  final  signals.  Subsequently  the 
computer  generates  the  Individual  Signal  Probability  Distributions  for 
each  of  these  signals.  In  this  case  the  probability  distribution  for 
signal  #8  is  repeated  in  slightly  different  format. 

The  G03  output  also  lists  the  CPU  time  for  execution,  the  direct  I/O 
count,  and  the  elapsed  clock  time. 

As  noted  above  the  reliability  for  this  series  system  of  two  components 
was  calculated  by  G03  to  be  0.9267181.  This  value  can  be  obtained  directly 
from  equation  1,  page  34  where 


r  =  0.9394  •0.9865  =  0.9267181. 
s 

This  substantiates  the  result  generated  from  the  GO  software.  Of  course,  for 
such  a  trivial  problem  the  GO  methodology  is  not  required,  and  it  is  only  used 
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here  for  illustrative  purposes.  The  benefits  from  employing  GO  become 
significant  when  one  cannot  write  the  system  success  equation  by  inspection. 


The  event  tree  which  is  developed  by  the  GO  model  for  this  system  is 
shown  in  Figure  31.  After  the  operator  representing  component  A  is  executed 
in  G03  two  branches  exist,  the  upper  branch  with  event  3  and  the  lower  branch 
with  event  3  .  Then,  the  second  operator  representing  component  B  is 
introduced.  four  branches  are  generated.  One  represents  the  success  event, 
8^.  The  other  three  branches  lead  to  system  failure,  event  8^.  They  are 

combined  and  their  probabilities  summed  to  generate  the  probability  of  system 
failure.  (This  can  be  done  because  the  different  branches  of  the  tree  are 

mutually  exclusive.) 

Without  changing  the  logical  configuration  of  this  system,  we  will 
calculate  another  reliability  performance  measure  based  on  different  data.  In 
the  execution  of  this  model  as  treated  above,  we  calculated  system  reliability 
from  component  reliabilities  which  were  based  upon  the  proportion  of  successes 
obtained  in  n  trials.-  Time  was  not  a  factor  in  these  estimates,  and 

consequently,  the  system  reliability  estimate  is,  without  further  information, 
time  invariant. 

In  contrast,  we  new  postulate  that  the  components  are  degrading  with 

time,  the  degradation  being  specified  by  failure  rates  of  6.27x10 
failures/hour  and  3.42x10  failures/hour  for  components  A  and  B  respectively. 
By  specifying  the  failure  rate  we  mean  that  the  components  exhibit  an 
exponential  time-to-f ailure  distribution.  In  this  instance  time  is  very  much 
a  parameter.  Now  the  proper  question  is,  nwhat  is  the  system  reliability 
after  so  many  hours  of  service  assuming  no  repair?*1 


To  calculate  the  system  reliability  at,  say,  5000 
calculate  the  component  reliabilities  at  that  time.  Since, 


hours,  we  first 


where 
componen 


r .  =  e 

l 


-Pit 


r . 

l. 


is  the  reliability,  and 


pi 


the  failure  rate  of  the 


,  th 


The  reliability  is  calculated  at  time  t.  Hence, 


-6.27x10  6  •  5xl03  n  0,01 
r.  =  e  =  0.9691 

A 

r  =  e_3-42x10  *5x10  =  0>  9830 

B 


When  this  data  is  entered  in  G02  and  the  system  model  executed,  the 
system  reliability  at  5000  hours  is  calculated  to  be  0.9526253.  Obviously  the 
system  reliability  can  be  obtained  for  any  point  in  time.  A  number  of  such 
estimates  were  calculated  to  generate  the  curve  of  Figure  32.  (This  was  done 
using  the  repetitive  option  in  G03  -  see  GO  Reference  Manual  for  details.) 
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FIGURE  31 

EVENT  TREE  FOR  SERIES  SYSTEM  OF  TWO  COMPONENTS 
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Reliability 


FIGURE  32  RELIABILITY  WITH  TIME, 

NO  RFPAIR,  SERIES  SYSTEM  OF  TWO  COMPONENTS 
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As  a  final  variation  of  the  data  which  might  be  used  to  calculate  a 
performance  measure  for  the  series  system  of  two  components,  let  us  now 
postulate  that  when  a  component  fails  it  is  detected  immediately  and 
repaired.  We  now  seek  the  proportion  of  the  time  the  components  and  the 
system  are  functional,  e.g.,  their  availability. 

To  generate  the  availability  point  estimates  for  the  components  we  need 
some  information  about  the  length  of  time  repairs  take.  Knowing  that  the 
average  repair  times,  or,  more  commonly,  the  mean-times-to-repair  (MTTR) ,  for 
component  A  and  B  are  four  and  16  hours  respectively,  for  example,  permits  us 
to  calculate  the  availability  of  each  component.  This  is  done  using  the 
standard  formula 


MTTF 

MTTF  +  MTTR  * 

The  MTTF  can  be  obtained  as  the  reciprocal  of  the  failure  rate.  Using  the 
failure  rates  specified  above,  the  MTTF  for  components  A  and  B  are  159489.6 
and  292397.7  hours  respectively.  The  availabilities  of  components  A  and  B  are 
then : 


a 


A 


a 


B 


159489.6 
159489.6+4 

292397.7 
292397.7+16 


0.999975 

0.999945 


Using  these  probabilities  as  the  component  data  for  G02,  the  system 
availability,  a^,  can  be  calculated.  It  is,  0.999920.  (One  can  use 
equation  4.2  to  calculate  this  result  for  comparison.)  The  effect  of 
repairs  upon  system  performance  is  seen  to  be  pronounced.  The 

probability  that  the  system  is  functional  at  any  random  point  in  time 
(its  availability)  is  0.999920,  whereas,  without  repair,  the  reliability 
degrades  quite  rapidly  with  time  as  previously  noted  in  Figure  32. 


We  now  observe  that  the  GO  model  of  Figure  26  for  this  series  system  of 
two  components  is  not  unique.  Shown  in  Figure  33  are  four  additional  ways  the 
model  could  have  been  constructed  to  generate  identical  results. 


The  preparation  of  the  data  for  these  GO  models  is  left  as  an  exercise 
for  the  reader.  Refer  to  Figures  11  and  14  for  the  G01  and  G02  data  formats 
for  different  operator  types. 


In  this  example  we  have  demonstrated  how  a  GO  model  for  this  simple 
two-component  system  is  developed.  We  executed  the  model  with  three  different 
types  of  data  -  bionomial  attribute  data,  reliability  with  tame  data,  and 
availability  data.  The  model  input  and  output  data  were  shown  and  explained 
in  detail.  Finally  we  demonstrated  other  ways  the  system  could  have  been 
modeled . 
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FIGURE  33 

|  EQUIPMENT  GO  MODELS  FOR  SERIES  SYSTEM 
OF  TWO  COMPONENTS 
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Example  2  -  Parallel  System  of  Two  Components 

This  example  is  an  extension  of  Example  1.  Its  purpose  is  to 
portray  another  simple  example  so  the  reader  gains  familiarity  with  the 
procedure  on  models  he  can  easily  comprehend  and  check.  The  same 
components  and  data  will  be  used,  but  the  system  configuration  is  now  a 
simple  parallel  system  in  contrast  with  the  series  system  of  Example  1. 
Figure  34  depicts  the  system.  If  either  component  is  successful,  the 
system  is  successful. 


COMPONENT  A 


FIGURE  34  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 


To  calculate  system  reliability  the  GO  model  of  Figure  35  is 
constructed . 


I  FIGURE  35  GO  MODEL  OF  PARALLEL  SYSTEM]- EM  VI 
OF  TWO  COMPONENTS 
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The  GO  data  to  execute  this  model  is  listed  in  Figure  36. 


G01  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 
$PARAM  INFIN=1$ 

5  1  1  $  COMPONENT  A 
5  2  2  $  COMPONENT  B 
2  0  2  1  2  3  $  OR  GATE 
03$  FINAL  SIGNAL 
EOR 

G02  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 
$PARAM  $ 

1520  0.9394  1  0.0606  $  COMPONENT  A 
2520  0.9865  1  0.0135  $  COMPONENT  B 
EOR 

GO 3  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 
$PARAM  PMIN=0. 0  $ 

EOR 


FIGURE  36  GO  DATA  FOR 
PARALLEL  SYSTEM  OF  TWO  COMPONENTS 

The  results  from  executing  this  model  by  the  GOl,  G02,  and  G03  software 
are  recorded  in  Figures  37,  38,  and  39  respectively.  Of  most  interest  is  the 
reliability  of  the  parallel  system.  From  the  Final  Event  Table  of  Figure  39, 
the  calculated  system  reliability  is  0.9991819.  One  can  double  check  this 
result  from  the  formula, 

r  =  r  +  r  -  r  •  r  =  0.9394  +  0.9865  -  0.9267181  =  0.9991819. 
s  a  b  a  b 

Example  3  -  Treatment  of  Dependencies 

The  purpose  of  this  example  is  to  explore  the  treatment  of  statistical 
dependencies  in  a  GO  model.  Such  dependencies  are  common  factors  in  most 
systems.  Often  two  or  more  components  rely  upon  common  power  sources,  common 
human  actions,  common  environments,  common  water  supplies,  etc.  The  proper 
accommodation  of  such  dependencies  is  crucial  to  the  assessment  of  most  real 
systems.  This  example  demonstrates  that  GO  models  easily  accommodate 
dependencies  and  that  the  GO  software  properly  calculates  the  probabilities  of 
occurrence  of  dependent  events. 

Consider  the  system  whose  GO  model  is  shown  in  Figure  40.  Two  pumps  each 
have  a  common  water  source  and  a  common  power  source.  The  model  documents 
that  the  output  from  both  pumps  is  required  for  system  success  by  requiring 
both  inputs  to  an  "AND"  gate  to  generate  system  success. 
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GO  1  <  KSCGO  t  VAX  VERSION  l.O)  RUN  ON  19-0CT-B2  AT  .1.5:33526 

COPYRIGHT  (C)  1982  bn  KAMAN  SCIENCES  CORPORATION 

601  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 


INFIN  «  1 7  VALUES 


OP  DATA 


2?  BIAS  =  750  7  OPS  =  1 7  SIGNALS  •-  1, 

ERRORS  -  25 


1  5  1  1  $  COMPONENT  A 

2  5  2  2  $  COMPONENT  B 

3  2  0  2  1  2  3  $  OR  GATE 

///A  0  3*  FINAL  SIGNAL 

SIGNAL  DATA 


SOURCE  0 PER* 

SIGNAL  NUM  TYPE  KIND  USING  OPERATORS  <-  IF  DELETED  AT) 


1  15  1-3 

2  2  5  2  -3 

3  3  2  0 

OPERATOR (NUMBER  OF  ACTIVE  SIGNALS) 


1  (  1  )  2  (  2 )  3  (  1  ) 

NUMBER  OF  OPERATORS , ♦ ♦  ~  3 

NUMBER  OF  SIGNALS,...,  -  3 

MAXIMUM  NUMBER  ACTIVE.  -  2 

MAX  SIGNAL  LIST  SIZE,,  *  2 

NUMBER  OF  SIGNALS/WORD  -  32 

MAXIMUM  WORDS/TERM.,.,  =  1 

FINAL  SIGNALS  =  3 

CPU  TIME  -  0:00:00.43 
DIRECT  I/O  COUNT  =  5 
ELAPSED  TIME  ~  00  I  00  .*01. 30 


FIGURE  37 

G01  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 


49 


002  <  KSCGQ »  VAX  VERSION  1.0)  RUN  ON  19-0CT-82  AT  15  *.33: 28 

COPYRIGHT  (C)  1982  b'J  KAMAN  SCIENCES  CORPORATION 

GO 2  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 

PERF  ~  0  7  MXSIZE  ~  2048 

OPERATOR  FILE  -  G01  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 

RECORD  KIND  DATA 

1  1520  0.9394  1  0.0606  $  COMPONENT  A 

2  2520  0.9865  1  0.0135  $  COMPONENT  B 


USE  SUMMARY  TABLE.  ENTRY  =  K IND/TYPE ( FREQUENCY ) 
(FREQUENCY  IS  NEGATIVE  FOR  PERFECT  KINDS.) 

1/  5(  1)  2/  5(  1) 

NUMBER  OF  KINDS  INPUT -  2 

NUMBER  USED  -  NON PERFECT--  2 

NUMBER  USED  -  PERFECT -  0 

1  FILE  RECORDS  WRITTEN  FOR  3  OPERATORS. 

CPU  TIME  -  O'.  00J00.35 
DIRECT  I/O  COUNT  =  13 
ELAPSED  TIME  ~  00  I  00  t  01 . 25 


FIGURE  38  G02  DATA  FOR  PARALLEL  SYSTEM 
OF  TWO  COMPONENTS 
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GO 3  ( KSCGO  >  VAX  VERSION  1.0)  RUN  ON  19-0CT-82  AT  15133:30 
COPYRIGHT  (C)  1982  bu  KAMAN  SCIENCES  CORPORATION 

G03  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 

OPERATOR  FILE  -  G01  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 

KIND  FILE  -  G02  DATA  FOR  PARALLEL  SYSTEM  OF  TWO  COMPONENTS 

RUN  NUMBER  1 

PMIN  =0. 0000 E +00 

NEW  «=■  0»  INTER  =  0>  SAVE  »  Of  MXDIST  »  3000 
FIRST  *  10000?  LAST  ~  10000?  TRACE  =  2.00000 


FINAL  EVENT  TABLE  (INFINITY  «  1) 

SIGNALS  AND  THEIR  VALUES 


PROBABILITY  3 


0.0008181000  1 

0  9991819000  0 


TOTAL  PROBABILITY  -  1.0000000000 

TOTAL  ERROR  =  0.0000000000 


INDIVIDUAL  SIGNAL  PROBABILITY  DISTRIBUTIONS 
VAL.  3 


0  0.9991319000 

1  0.0008181000 


CPU  TIME  ~  0*.  00 100.36 
DIRECT  I/O  COUNT  =  7 
ELAPSED  TIME  =  00*.00:00.79 


FIGURE  39  G03  DATA  FOR  PARALLEL  SYSTEM 
OF  TWO  COMPONENTS 
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FIGURE  40 

GO  MODEL  DEPENDENCIES  BOTH  PUMP  TRAINS  REQUIRED 


It  is  obvious  from  the  model  that  both  pumps  depend  upon  the  common  water 
and  power  sources.  Consequently  signals  3  and  4  are  not  independent.  To  show 
that  the  G03  type  10  algorithm  for  an  "AND"  gate  properly  accommodates  the 
dependencies  of  any  input  signals  we  will  write  the  equations  for  system 
success  and  compare  the  probabilities  of  occurrences  calculated  by  equations 
to  the  output  from  the  GO  software. 


Let  S.  be  the  event  that  signal  i  is  successful.  then  represents 
the  availability  of  water  and  the  availability  of  power.  Let  be  the 
event  that  pump  A  is  successful  and  likewise  for  P  .  The  derived  events 
S^,  ,  and  can  now  be  expressed  as  a  function  of  the  elemental  events. 
Set  theory  notation  for  the  intersection  of  events  is  represented  thus,  fl  . 


S 


S 

S 


3 

4 

5 


=  s  n  s  n  pa 
= s  ns  npj 
=  s  ns  npjnp. 


B 


If  s.  now  represents  the  probability  of  event  S.  and  p^  and  p^ 
represent  \he  probabilities  of  pumps  A  and  B  working  properly,  then  the 


probabililties  for  events  S 


P(SJ  =  s 
P(S  )  =  S 
PCS*)  =  sj 


3’  ‘ 

PA’ 
PB  ’ 
PA  * 


V 


and 


can  be  expressed  as  follows: 


v 


These  equations  demonstrate  that  the  probability  of  occurrence  of  event 
is  not  the  algebraic  product  of  the  probabilities  of  events  and  S^. 

Because  of  their  common  dependencies  upon  the  same  power  and  water  sources, 
the  Boolean,  rather  than  the  algebraic,  product  of  their  probabilities  of 
occurrence  provides  the  correct  probabilities  of  occurrence  for  event  S^. 


Pursuing  this  example  let  the  following  quantitative  estimates  for  the 
probabilities  of  occurrence  of  the  elemental  events  previously  defined  be: 


s 

s 

P 


1 

2 

A 


0.95 

0.99 


0.9 
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Consequently  the  probabilities  of  S^,  S^,  and  (to  four  places) 

are : 

s  =  0.8465, 
s^  =  0.8465, 
s^  =  0.7618. 

If  the  dependencies  upon  the  common  power  and  water  sources  had  been 
ignored,  as  is  often  incorrectly  postulated,  and  events  and  had  been 
treated  as  if  independent,  the  probability  of  event  occurring  would  be 
computed  to  be  (0.8465)  =  0.7166.  The  difference  between  this  value  and  the 
correct  value  of  0.7618  is  0.0452,  a  nontrivial  discrepancy. 

This  model  was  executed  using  the  GO  software.  The  permissable  values 
the  random  variables  may  take  are  0  (success)  and  1  (failure).  G01,  G02,  and 
G03  data  were  developed  from  the  information  above.  The  results  are  shown  in 
Figures  41,  42,  and  43.  Notice  that  the  probability  of  event  5^,  which 
represents  system  success  in  Figure  43,  is  0.7618,  the  correct U  answer. 
Consequently  the  GO  software  properly  accounts  for  signal  dependencies. 

The  event  tree  generated  by  the  GO  software  for  this  model  is  shown  in 
Figure  44.  The  tree  depicts  how  the  GO  model  generates  the  events  and  their 
probabilities  of  occurrence. 

As  a  variation,  redefine  system  success  to  be  proper  function  of  either 
pump.  In  this  case,  the  type  10  in  Figure  40  is  replaced  with  a  type  2  "OR" 
gate. 


The  event  equation  for  system  success  is  now: 

s5-  Slns2n<pAupB). 

The  probability  of  occurrence  then  becomes: 

P(s5)  -  Si  .  s2  <pA  *  PB  -  PA  PB). 

Using  the  same  data  as  before, 

P(S5)  =  0.95  •  0.99  (0.9  +  0.9  -  0.81)  =  0.9311. 

If  and  were  incorrectly  considered  to  be  independent,  then  the 

probability  of  system  success  would  be  0.9764  calculated  as  follows: 

P(s  )  =  P(S.  Us.)  =  s.+s-s.s.  =  0.8465+0. 8465-0. 84652  =  0.9764. 

5  3  4  3  4  3  4 

Again  the  difference  is  not  inconsequential,  and  the  treatment  of  dependencies 
is  seen  to  be  important  in  developing  system  event  probabilities. 

Figures  45,  46,  and  47  record  the  G01,  G02,  and  G03  output  for  system 
success  with  the  new  success  criteria  -  either  pump  successful.  Note  that 


53 


GO  1  ( KSC60 1  MAX  VERSION  1.0)  RUN  ON  20-0CT-82  AT  15J35143 

COPYRIGHT  (C)  1982  by  KAMAN  SCIENCES  CORPORATION 

001  DATA  FOR  GO  MODEL  DEPENDENCIES  -  BOTH  PUMPS 

INF  IN  ~  1 7  VALUES  ~  2?  BIAS  -  750?  OPS  -  1?  SIGNALS  «  X? 

ERRORS  -  25 


OP  DATA 


1  5  1  1  $  WATER  SOURCE 

2  5  2  2  $  POWER  SOURCE 

3  6  3  1  2  3  $  PUMP  A 

4  63124$  PUMP  B 

5  10  0  2  3  4  5  $  AND  GATE 

///£  0  5  $  FINAL  SIGNAL 


SIGNAL  DATA 

SOURCE  OPER. 

SIGNAL  NIJM  TYPE  KIND  USING  OPERATORS  <-  IF  DELETED  AT) 


1 

O 

3 

4 


15  1  3  -  4 

2  5  2  3  -  4 

3  6  3  -5 

4  6  3  -5 

5  10  0 


OPERATOR ( NUMBER  OF  ACTIVE  SIGNALS) 


NUMBER  OF  OPERATORS...  «  5 
NUMBER  OF  SIGNALS....,  ~  5 
MAXIMUM  NUMBER  ACTIVE.  «  3 
MAX  SIGNAL  LIST  SIZE.,  -  3 
NUMBER  OF  SIGNALS/WORD  «  32 
MAXIMUM  WORDS/TERM...,  ~  1 


FINAL  SIGNALS  »  5 

cpu  time  -  0:00:00. 56 

DIRECT  I/O  COUNT  =  6 
ELAPSED  TIME  --  00 1 00  5  02.29 


FIGURE  41  G01  DATA  FOR  GO  MODEL  DEPENDENCIES  - 
BOTH  PUMP  TRAINS  REQUIRED 
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0)02  <  KSC60 »  VAX  VERSION  1.0)  RUN  ON  20-0CT-82  AT  15*.35*.47 

COPYRIGHT  (C)  1982  b'J  KAMAN  SCIENCES  CORPORATION 

002  DATA  FOR  GO  MODEL  DEPENDENCIES  -  BOTH  PUMPS 

PERF  -  07  MXSIZE  «  2048 

OPERATOR  FILE  -  G01  DATA  FOR  GO  MODEL  DEPENDENCIES  -  BOTH  PUMPS 

RECORD  KIND  DATA 


1  1520  0,95  1  0.05  *  WATER  SOURCE 

2  2520  0.99  1  0.01  $  POWER  SOURCE 

3  360.90.10.0$  PUMP 


USE  SUMMARY  TABLE ♦  ENTRY  «  K I ND/TYPE ( FREQUENCY > 
(FREQUENCY  IS  NEGATIVE  FOR  PERFECT  KINDS.) 


1/  5(  1)  2/  5( 

1  ) 

3/  6 (  2) 

NUMBER  OF  KINDS  INPUT  — 

3 

NUMBER  USED  -  NONPERFECT— 

3 

NUMBER  USED  -  PERFECT - 

0 

1  FILE  RECORDS  WRITTEN 

FOR 

5  OPERATORS 

CPU  TIME  -  0:00’.00,47 

DIRECT  I/O  COUNT  «  13 

ELAPSED  TIME  =  OO’.OO  :  02 . 46 

FIGURE  42  G02  DATA  FOR  GO  MODEL  DEPENDENCIES  * 
BOTH  PUMP  TRAINS  REQUIRED 
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M04  ( KSCGO  »  VAX  VERSION  1.0)  RUN  ON  20-0CT-82  AT  15:35)51 

COPYRIGHT  (C)  1982  by  KAHAN  SCIENCES  CORPORATION 

G 0 3  DATA  FOR  GO  MODEL  DEPENDENCIES-  BOTH  PUMPS 


OPERATOR  FILE  ---  G01  DATA  FOR  GO  MODEL  DEPENDENCIES  -  BOTH  PUMPS 
IUND  FILE  -  G02  DATA  FOR  GO  MODEL  DEPENDENCIES  -  BOTH  PUMPS 


RUN  NUMBER  1 

PMIN  ”0 . OOOOE+OO 

NEW  =  Or  INTER  «■  Or  SAVE  »  Or  MXDIST  =  3000 

FIRST  «  1 0000  ?  LAST  ~  10000 r  TRACE  «  2.00000 


FINAL  EVENT  TABLE  (INFINITY  -  1) 

SIGNALS  AND  THEIR  VALUES 

PROBABILITY  5 

0 . 2381950000  1 

0.76)8050000  0 


TOTAL  PROBABILITY  -  1.0000000000 

TOTAL  ERROR  =  0.0000000000 


INDIVIDUAL  SIGNAL  PROBABILITY  DISTRIBUTIONS 

VAL.  5 

0  0.7613050000 

1  0.2381950000 


CPU  TIME  «  0:00:00.36 
DIRECT  I/O  COUNT  -  6 
ELAPSED  TIME  --  00  .*00. *00.88 


FIGURE  43  G03  DATA  FOR  GO  MODEL  DEPENDENCIES  ■ 
BOTH  PUMP  TRAINS  REQUIRED 
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FIGURE  44  EVENT  TREE  FOR  GO  MODEL  DEPENDENCIES  - 
BOTH  PUMP  TRAINS  REQUIRED 
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GO  1  ( KSCGO  r  VAX  VERSION  1.0)  RUN  ON  20-0CT-82  AT  15M2M4 

COPYRIGHT  (C)  .1.932  bu  KAHAN  SCIENCES  CORPORATION 

GO 1  DATA  FOR  GO  MODEL  DEPENDENCIES  -  EITHER  PUMP 


INF  IN  «  1;  VALUES  «  2?  BIAS 

OP  DATA 


1 

Kr 

O 

1 

1 

$ 

WATER  SOURCE 

0 

5 

2 

2 

* 

POWER  SOURCE 

3 

L 

C- 

3 

1 

•p 

■7 

%  PUMP  A 

4 

6 

3 

1 

2 

4 

f  PUMP  B 

5 

9 

0 

0 

3 

4 

5  $  OR  GATE 

///A 

0 

5 

$ 

F 

INAL  SIGNAL 

-  750 t  OPS  «  1;  SIGNALS  «  1; 

ERRORS  ~  25 


SIGNAL  DATA 

SOURCE  QPER. 

SIGNAL  N.UM  TYPE  KIND  USING  OPERATORS  (-  IF  DELETED  AT) 

1  15  1  3-4 

2  2  5  2  3  -4 

3  36  3-5 

4  46  3  -5 

5  5  2  0 

OPERATOR ( NUMBER  OF  ACTIVE  SIGNALS) 


1  ( 

1 ) 

2  (  2) 

3  ( 

3) 

NUMBER 

OF 

OPERATORS . . . 

5 

NUMBER 

OF 

SIGNALS. .... 

5 

MAXIMUM 

NUMBER  ACTIVE. 

rz 

3 

MAX  SIGNAL 

LIST  SIZE. > 

ir: 

3 

NUMBER 

OF 

SIGNALS/WORD 

ns 

32 

MAXIMUM  WORDS/TERM....  «  1 


FINAL  SIGNALS  = 


CPU  TIME  «  0100:00.50 
DIRECT  I/O  COUNT  =  6 
ELAPSED  TIME  -  00100101.47 


FIGURE  45  G01  DATA  FOR  GO  MODEL  DEPENDENCIES  - 
EITHER  PUMP  TRAIN  REQUIRED 


58 


G02  ( KSCGO  r  VAX  VERSION  1.0)  RUN  ON  20-0CT-82  AT  15M2146 

COPYRIGHT  (C)  1982  by  KAMAN  SCIENCES  CORPORATION 

G02  DATA  FOR  GO  MODEL  DEPENDENCIES  -  EITHER  PUMP 

PERF  -  0?  MXSIZE  »  2048 

OPERATOR  FILE  -  G01  DATA  FOR  GO  MODEL  DEPENDENCIES  -  EITHER  PUMP 

RECORD  KIND  DATA 

1  1  5  2  0  0.95  1  0.05  $  WATER  SOURCE 

2  2  5  2  0  0.99  1  0.01  $  POWER  SOURCE 

3  3  6  0.9  0.1  0.0  $  PUMP 


USF  SUMMARY  TABLE.  ENTRY  «  K I ND/TYPE ( FREQUENCY  ) 
(FREQUENCY  IS  NEGATIVE.  FOR  PERFECT  KINDS.) 

1/  5<  1)  2/  5(  1)  3/  6(  2) 

NUMBER  OF  KINDS  INPUT -  3 

NUMBER  USED  -  NONPERFECT--  3 

NUMBER  USED  -  PERFECT -  0 

1  FILE  RECORDS  WRITTEN  FOR  5  OPERATORS. 

CPU  TIME  =  0100:00,42 
DIRECT  I/O  COUNT  **13 
ELAPSED  TIME  =00100101,12 


FIGURE  46  G02  DATA  FOR  GO  MODEL  DEPENDENCIES  * 
EITHER  PUMP  TRAIN  REQUIRED 
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G 0 3  (KSCGOf  VAX  VERSION  1.0)  RUN  ON  20-0CT-82  AT  15M2MB 
COPYRIGHT  (C)  1982  bu  KAMAN  SCIENCES  CORPORATION 

003  DATA  FrOR  GO  MODEL  DEPENDENCIES  -  EITHER  PUMP 


OPERATOR  FILE  -  G01  DATA  FOR  GO  MODEL  DEPENDENCIES  -  EITHER  PUMP 

KIND  FILE - G02  DATA  FOR  GO  MODEL  DEPENDENCIES  -•  EITHER  PUMP 


RUN  NUMBER  1 

PMIN  =0 . OOOOE+OO 

NEW  =  Or  INTER  =  Or  SAVE  “  Or  MXDIST  =  3000 

FIRST  =»  1 0000  r  LAST  *  10000;  TRACE  -  2,00000 


FINAL  EVENT  TABLF  (INFINITY  «  1) 

SIGNALS  AND  THEIR  VALUES 


PROBABILITY  5 

0.0689050000  1 

0.9310950000  0 


TOTAL  PROBABILITY  1.0000000000 

TOTAL  ERROR  =  0.0000000000 


INDIVIDUAL  SIGNAL  PROBABILITY  DISTRIBUTIONS 

VAL. ,  5 


0  0.9310950000 

1  0.0689050000 


CPU  TIME  0:00:00.35 
DIRECT  I/O  COUNT  -  6 
ELAPSED  TIME  -  00  J  00  ‘.00. 53 


FIGURE  47  G03  DATA  FOR  GO  MODEL  DEPENDENCIES  - 
EITHER  PUMP  TRAIN  REQUIRED 
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event  5q,  system  success,  occurs  with  probability  0.9311.  This  is  the  correct 
value,  again  establishing  the  validity  of  the  KSC  GO  algorithms  for  handling 
dependent  events. 

The  event  tree  for  this  revised  model  is  shown  in  Figure  48.  It  is 
identical  to  the  event  tree  of  Figure  44  except  for  the  combination  of  the 
branches  in  an  OR  gate,  rather  than  an  AND  gate,  in  the  final  column. 

These  two  models  have  demonstrated  how  dependent  events  are  modeled  and 
manipulated  in  the  GO  software  to  generate  the  correct  probabilities  of 
occurrence  of  all  events. 

Example  4  -  Alarm  System 

This  alarm  system  is  somewhat  more  complex  than  the  previous  examples. 
In  this  example  system,  we  introduce  three  values  which  the  random  variables 
may  take.  These  values  represent  component  and  system  operational  responses 
of  premature,  success,  and  failure.  The  use  of  type  6  operators,  the 
definition  and  use  of  a  supertype,  and  the  request  for  a  final  joint 
distribution  involving  three  signals  are  also  portrayed  in  this  example. 

Figure  49  depicts  a  quadruply  redundant  alarm  system  with  two 
two-out-of-three  detector  and  alarm  systems  receiving  the  sensor  outputs.  The 
two-out-of-three  detectors  are  used  to  prevent  false  alarms  caused  by  sensor 
malfunction  —  transmitting  a  signal  when  the  sensed  event  has  not  occurred. 
Presumably  false  alarms  are  a  costly  nuisance  and  the  alarm  system  design 
attempts  to  preclude  them  by  requiring  that  at  least  two  sensors  must  give  the 
same  response  to  trigger  an  alarm.  An  alarm  will  be  sounded  if  either  of  the 
two  detector  and  alarm  units  respond,  given  the  occurrence  of  the  monitored 
event . 

Figure  50  is  the  GO  model  developed  for  this  system.  Type  6  operators 
having  three  operational  modes  —  premature,  success,  and  failure  —  are  used 
to  represent  the  sensors.  Supertype  150  is  defined  with  three  inputs  and  one 
output  to  model  a  two-out-of-three  detector  and  alarm  unit.  The  supertype  is 
then  used  twice  in  the  system  model.  Signals  10  and  20  are  the  signals  for 
channels  A  and  B,  and  signal  100  is  the  system  output  signal. 

In  this  model  we  define  three  values  which  the  signals  may  take. 
These  are: 

VALUE  DEFINITION 

0  Premature  operation;  occurs 
before  alarm  event 

1  Time  at  which  alarm  event  occurs 

2  Never 

The  printouts  from  G01  and  G02  document  the  conf iguration  and  the  data 
for  the  alarm  system.  They  are  provided  in  Figures  51  and  52.  There  are  15 
operators  in  G01,  with  a  maximum  number  of  five  active  signals.  Six  different 
kinds  of  component  data  are  defined. 


61 


EITHER  PUMP  TRAIN  REQUIRED 
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Main  Battery 


\|^AIarm  Event 


ALARM  SYSTEM 


2/3  Logic 


Alarm 


Alarm  Battery 


2/3  DETECTOR  AND  ALARM 


FIGURE  49  ALARM  SYSTEM 
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ALARM  EVENT 


B  CHANNEL 
DETECTOR  &  ALARM 


SENSOR  1 


A  CHANNEL 
DETECTOR  &  ALARM 


100 


ALARM 

SYSTEM 

RESPONSE 


SUPER  - 
TYPE  - 
150  8 


MAIN 

BATTERY 


SUPER¬ 

TYPE 

150 


2/3  DETECTOR  AND  ALARM 
1  SUPERTYPE  150 


ALARM 


FIGURE  50  GO  MODEL  OF  ALARM  SYSTEM 
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601 

( KSCGO  ? 

VAX  VERSION  1,0)  RUN 

ON  22-0CT-82  AT  16M8J04 

COPYRIGHT  (C)  1982  by  KAMAN  SCIENCES  CORPORATION 

GO  1  DATA  FOR 

ALARM  SYSTEM 

INFIN 

«  2  f 

VALUES  ~  3 i  BIAS  ” 

750  ?  OPS  «  h  SIGNALS  -  li  ERRORS  =  25 

OP 

DATA 

XXXX 

150  -1 

101  102  103  201  %  ST 

150  DEFINITION 

XXXI 

11  2  3 

101  102  103  1  $  2  OF 

3  GATE 

XXXI 

5  4  2 

$  ALARM  BATTERY 

XXXI 

6  5  1 

2  3  $  SWITCHC NORMALLY 

OPEN) 

XXXI 

1  6  3 

201  $  ALARM 

1 

EUREKA 

— 

END  OF 

SUPER  TYPE  150 

1 

5  1  1 

$  MAIM  BATTERY 

o 

5  2  2 

$  ALARM  EVENT 

3 

6  3  1 

2  11  $  SENSOR  1 

4 

6  3  1 

2  12  $  SENSOR  2 

5 

6  3  1 

2  13  $  SENSOR  3 

6 

6  3  1 

2  14  $  SENSOR  4 

$$$& 

150  0 

13  12  11  10  $  A  DETECTOR  AND  ALARM 

7 

( L~  1  ) 

11  2  3  13 

12  11  751  $$  A  DETECT2  OF  3  6 

8 

<L-i  > 

5  4  752  $$  A 

DETECT ALARM  BA 

o 

/ 

(  L  ~  1  > 

6  5  751  752 

753  $$  A  DET  ECT8WITCH ( N 

10 

<L*1) 

1  6  753  10 

$$  A  DETECTALARM 

150  0 

14  13  12  20  t  B  DETECTOR  AND  ALARM 

1  1 

( L  ~  1  ) 

11  2  3  14 

13  12  754  $$  B  DETECT2  OF  3  G 

12 

(  L  ”  1 ) 

5  4  755  $$  B 

DETECTALARM  BA 

1 3 

( L  « 1  > 

6  5  754  755 

756  B  DE.TECTSWITCH ( N 

1  4 

(L-l ) 

1  6  756  20 

$$  B  DETECTALARM 

15 

2  0  2 

10  20  100  $  OR  GATE 

/ /ll 

0  10  20  100  %  SIGNALS  FOR  A 

CHANNEL?  B  CHANNEL  t  AND  SYSTEM 

FIGURE  51  G01  OUTPUT  FOR  ALARM  SYSTEM 
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FIGURE  51  (CONTINUED) 


G02  ( KSC60  >  VAX  VERSION  1.0)  RUN  ON  22-0CT-82  AT  16*.  48 ‘.08 

COPYRIGHT  (C)  1982  b y  KAMAN  SCIENCES  CORPORATION 

G02  DATA  FOR  ALARM  SYSTEM 

PERF  -  Or  MXSIZE  «  2048 

OPERATOR  FILE  -  G01  DATA  FOR  ALARM  SYSTEM 

RECORD  KIND  DATA 

1  15200. 98  20, 02$  MAIN  BATTERY 

2  2  5  1  1  1.0  $  ALARM  EVENT 

3  3  6  0.97  0.02  0.01$  SENSOR 

4  4520  0.99  2  0.01  $  ALARM  BATTERY 
556  0.990  0,007  0.003  $  SWITCH 

6  6  1  0.99  0.01  $  ALARM 


USE  SUMMARY  TABLE.  ENTRY  -  KIND/TYPE ( FREQUENCY ) 

(FREQUENCY  IS  NEGATIVE  FOR  PERFECT  KINDS,  ) 

1/  5(  1)  2/  5(  1)  3/  6(  4)  4 /  5 (  2)  5/  6(  2) 

6/  1C  2) 

NUMBER  OF  KINDS  INPUT -  6 

NUMBER  USED  -  NONPERFECT--  6 

NUMBER  USED  -  PERFECT -  0 

1  FILE  RECORDS  WRITTEN  FOR  15  OPERATORS, 

CPU  TIME  0:00:00. 6i 
DIRECT  I/O  COUNT  -  14 
ELAPSED  TIME  -  00J00:01.76 


FIGURE  52  G02  OUTPUT  FOR  ALARM  SYSTEM 
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The  results  obtained  from  executing  this  model  are  recorded  in  Figure  53. 
Referring  to  the  portion  of  the  figure  entitled  Individual  Signal  Probability 
Distributions,  the  output  distributions  for  signals  10,  20,  and  100,  which 
represent  channel  A,  channel  B,  and  the  system  (either  channel  A  or  channel 
B) ,  are  shown. 

The  probability  of  a  single  channel  (signal  10  or  signal  20)  functioning 
properly  is  0.9524.  The  probability  of  failure  on  a  single  channel  is  0.0473. 
The  probability  of  a  false  alarm  (premature)  on  a  single  channel  is  3x10 

_Jhe  alarm  system  has  premature,  success,  and  failure  probabilities  of 
5x10  ,  0.9784,  and  0.0211  respectively.  Notice  that  the  false  alarm  rate  for 
the  system  is  approximately  double  that  for  a  single  channel.  The  system 
failure  rate  is  about  half  that  for  a  single  channel. 

The  Final  Event  Table  of  Figure  53  shows  the  complete  joint  distribution 
of  signals  10,  20,  and  100.  The  most  likely  event  10^20^100^,  which  occurs 
with  probability  0.9260,. is  that  both  channels  and  the  system  are  successful. 
All  possible  events  expressed  as  the  combinations  of  premature,  success,  and 
failure  of  each  of  the  three  signals  are  recorded  with  their  respective 
probabilities  of  occurrence.* 

To  conclude,  this  example  has  documented;  (1)  the  use  of  three  values 
representing  premature,  success,  and  failure  operational  modes;  (2)  the  use  of 
type  6  operators;  (3)  the  use  of  supertypes;  and  (4)  multiple  output  signals 
in  the  final  joint  distribution. 

Example  5  -  Two-of-Three  Pump  Trains 

The  purpose  of  this  example  is  to  portray  the  development  of  a  GO  model 
for  a  slightly  more  complex  system,  introduce  the  type  11  operator  and  use  the 
model  to  simultaneously  generate  the  availability  of  two  different  pump  train 
designs . 

The  system  to  be  analyzed  is  represented  by  Figure  54.  A  company 
presently  has  a  pump  system  consisting  of  two  pump  trains  (pumps,  associated 
valves,  and  piping)  and  is  considering  a  proposed  system  of  three  pump  trains. 
The  present  system  is  representing  by  solid  lines  with  the  proposed  additional 
pump  train  in  dotted  lines.  What  will  be  the  increase  in  system  availability 
with  the  three  pump  train  system  over  the  present  system  if  two  pumps  must 
operate  to  provide  proposed  flow  and  pressure? 

Because  the  three  pump  trains  are  logically  identical  we  will  represent  a 
single  train  with  supertype  500.  Supertype  500  will  then  be  called  three 
times,  once  for  each  redundant  train. 

The  GO  model  for  this  system  is  documented  in  Figure  55. 

Because  this  is  an  availability  model,  the  signals  will  take  two  values 
0 (available)  and  1  (unavailable) .  Of  particular  interest  in  the  GO  model  for 
this  system  are  the  two  ways  in  which  we  have  combined  the  output  signals  from 
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G03  ( KSCGO  ?  VAX  VERSION  1.0)  RUN  ON  22-0CT-82  AT  16548510 

COPYRIGHT  (C)  1982  by  KAMAN  SCIENCES  CORPORATION 

G03  DATA  FOR  ALARM  SYSTEM 

OPERATOR  FILE  ---  G01  DATA  FOR  ALARM  SYSTEM 
KIND  FILE  -  G02  DATA  FOR  ALARM  SYSTEM 

RUN  NUMBER  1 

PMIN  -O.OOOOE+OO 

NEU  -  Of  INTER  «  0»  SAVE  «  0»  MXDIST  -  3000 

FIRST  =  10000 7  LAST  -  10000?  TRACE  "  2.00000 


FINAL  EVENT  TABLE  (INFINITY  -  2) 

SIGNALS  AND  THEIR  VALUES 
PROBABILITY  10  20  100 


0.0000076721 

0.0000076721 

0.0000946688 

0.0001818926 

0.0001818926 

0.0211465091 

0.0261715023 

0.0261715023 

0.9260366832 


0  2  0 

2  0  0 

0  0  0 

0  1  0 

1  0  0 

r>  o  9 

Am  Am  Am 

2  1  1 

1  2  1 

1  1  1 


TOTAL  PROBABILITY  *  1.0000000000 

TOTAL  ERROR  -  0.0000000000 


INDIVIDUAL  SIGNAL  PROBABILITY  DISTRIBUTIONS 


VAL.  10 


20 


100 


0 

1 


0.0002842335 

0,9523900830 

0.0473256835 


0.0002842335 

0.9523900830 

0.0473256835 


0.0004737982 

0.9783796927 

0.0211465091 


CPU  TIME  ~  0*00500.58 
DIRECT  I/O  COUNT  «  7 
ELAPSED  TIME  ~  00  500501.22 


FIGURE  53  G03  OUTPUT  FOR  ALARM  SYSTEM 
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FIGURE  54  PUMP  SYSTEM 


POWER 


FIGURE  55  GO  MODEL  FOR  PUMP  SYSTEM 
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the  pump  trains.  The  type  10  "AND"  gate  which  combines  signals  11  and  12,  the 
outputs  from  the  two  pump  trains  in  the  present  system,  generates  signal  20. 
Signal  20  represents  the  present  system. 

In  contrast,  signal  30,  the  output  from  the  type  11  operator  which  in 
this  case  is  a  2-of-3  gate,  represents  the  system  availability  for  the 
proposed  new  system  design. 


The  actual  G01  data  developed  for  this  model  and  input  to  the  computer  is 
portrayed  in  Figure  56.  Notice  that  we  first  defined  supertype  500  then  used 
it  thrice  in  the  system  model.  _ , _ 


GOI 

DATA  FOR  PUMP  SYSTEM  AVAILABILITY 

$  P  A  R  A  M  INFIM-1  $ 

500 

- 

1  101 

102  201  $  PUMP  TRAIN 

1  1 

101  1 

$  BUTTERFLY  VALUE 

1  2 

1 

2  i 

STRAINER 

6  3 

O 

102 

3  $  PUMP 

1  4 

3 

4  $ 

CHECK  VALUE 

6  5 

4 

102 

201  $  MOV 

END 

5  6 

1 

$  WATER  SOURCE 

5  7 

o 

$  POWER  SOURCE 

500 

0 

1  .2 

11  t  PUMP  TRAIN  1 

500 

0 

1  2 

12  ♦  PUMP  TRAIN  2 

500 

0 

1  2 

13  ♦  PUMP  TRAIN  3 

10  0 

2  11 

12  20  ♦  TU0  TRAINS 

11  2 

3  11 

12  13  30  ♦  TU0  OF  THREE  TRAINS 

0  20 

30  $ 

FINAL  SIGNALS 

FIGURE  56  GOI  INPUT  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 

The  GOI  output  for  this  system  model  is  recorded  in  Figure  57.  The  model 
consists  of  19  supertypes.  Signals  20  and  30  are  the  final  output  signals. 


The  G02  component  availability  data  for  this  model  are  actually  input  to 
the  computer  on  a  G02  data  input  file  as  recorded  in  Figure  58.  For  this 
system  it  was  assumed  that  the  component  availabilities  would  not  change  in 
the  2-of-3  system  over  the  2-of-2  system. 


G02 

DATA  FOR  PUMP 

SYSTEM  AVAILABILITY 

$P AR AM  $ 

1 

1 

0.9995  0.000 

5 

$  BUTTERFLY  VALVE 

n 

1 

0.9990  0.0010 

$  STRAINER 

3 

6 

0.995  0.005 

0. 

0  $  PUMP 

4 

1 

0.999  0.001 

$ 

CHECK  VALVE 

5 

6 

0.992  0.008 

0. 

0  $  MOV 

6 

5 

2  0  0.999  1 

0. 

001  $  WATER 

7 

5 

2  0  0.9999  1 

0 

.0001  $  POWER 

END 

FIGURE  58  G02  INPUT  DATA  FOR  SYSTEM  AVAILABILITY 

The  G02  output  data  for  this  model  is  recorded  in  Figure  58. 

The  two  lines  of  G03  input  data  for  this  model  are: 

G03  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 
$PARAM  PMIN=0 . 0$ 
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G01 

( KSCGO 

S 

VAX 

VERSION  1.0) 

RUN 

ON  26-0CT-S2  AT  11127:53 

COPYRIGHT  (C) 

1.982  bu  KAMAN  SCIENCES  CORPORATION 

GO 1  DATA  FOR 

PUMP  SYSTEM  AVAILABILITY 

IMF  IN 

"  1 

7 

VALUES  «  2  ?  BIAS  » 

750  r  OPS  «  If  SIGNALS  "  1; 

ERRORS  -  25 

OP 

DATA 

xxxx 

500  - 

1 

101 

102  201  $  PUMP  TRAIN 

XX  XX 

1  1  101 

1 

*  VALVE-BY 

xxxx 

1  2  1 

2 

$ 

STRAINER 

xxxx 

6  3  2 

102 

3  $  PUMP 

xxxx 

1  4  3 

4 

$ 

VALV-CHK 

xxxx 

6  5  4 

102 

201  %  MOV 

1 

END 

— 

END  OF 

SUPER  TYPE  500 

1 

5  6  1 

i 

WATER  SOURCE 

o 

5  7  2 

$ 

POWER  SOURCE 

500  0 

1 

n 

11  %  TRAIN  1 

3 

( L~  1  ) 

1  1  1 

751 

$$  TRAIN  1  VALVE-BY 

4 

(L-l) 

1  2  751 

752 

$$  TRAIN  1  STRAINER 

5 
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6  3  752 
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2 
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500  0 

1 

n 

13  $  TRAIN  3 
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(L-l  ) 

1  1  1 

759 

$$  TRAIN  3  VALVE-BY 

14 
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1  2  759 
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%%  TRAIN  3  STRAINER 

15 

(  L  ~  1  ) 

6  3  760 
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761  **  TRAIN  3  PUMP 

16 

(  L  - 1  ) 

1  4  761 
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TRAIN  3  VALV-CHK 

17 

( L  =  1  ) 

6  5  762 

2 

13  $$  TRAIN  3  MOV 

18 

10  0 

11 

12  20  $  TWO  TRAINS 

19 

11  2 

3 

1  1 

12  13  30  $  TWO 

OF 

THREE  TRAINS 

//20 

0  20 

30 

$ 

FINAL  SIGNALS 

FIGURE  57  G01  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 
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FIGURE  59  G02  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 


The  G03  output  data  is  shown  in  its  entirety  in  Figure  60.  The  Final 
Event  Table  of  Figure  60  records  the  joint  distributions  of  signals  20  and  30 
reflecting  the  system  availability  for  the  two  pump  train  configurations. 

The  Individual  Signal  Probability  Distributions  document  that  the 
availability  of  the  present  system  two  pump  trains  is  0.9683  (event  20  ) .  The 
proposed  new  2-of-3  pump  system  configuration  will  increase  availability  to 
0.9982  (event  30  ) . 

Being  able  to  quantify  the  performance  of  this  proposed  design  alteration 
quickly  provides  the  facts  necessary  to  determine  the  economic  benefits  and 
penalties  associated  with  its  proposal.  A  capable  GO  analyst  can  develop  the 
GO  model  of  a  system  of  this  complexity  and  execute  it  in  less  than  one  hour’s 
time . 


This  example  has  introduced  the  type  11  operators  and  demonstrated  the 
use  of  the  KSC  GO  methodology  to  simultaneously  generate  system  availability 
for  two  different  system  configurations. 

Example  6  -  Weapon  Fuzing  System 

The  purpose  of  this  example  is  to  demonstrate  the  application  of  the  GO 
methodology  to  analyze  the  safety  and  reliability  of  a  generic  weapon  fuzing 
system.  This  example  portrays  the  use  of  a  number  of  values  which  the  signals 
may  take  to  represent  premature  weapon  operation  (a  serious  safety  problem), 
success,  late  operation,  and  failure.  The  system  is  sufficiently  complex  that 
an  equation  for  its  operation  cannot  be  written  by  inspection  necessitating 
the  use  of  the  GO  methodology. 

The  fuzing  system  to  be  analyzed  is  shown  schematically  in  Figure  61. 
The  parallel  pairs  of  normally  open  contacts  are  safety  and  sequential  fuzing 
blocks  which  are  to  be  removed  at  different  times  to  send  proper  electrical 
signals  to  arm  and  fire  the  weapon  (not  shown).  Success  will  be  achieved  if 
the  following  combination  of  output  signals,  properly  sequenced  in  time,  are 
received : 


('a  u  V  0  0>audb)  n  (eau  v 

One  might  think  of  signals  C  and  as  pre-arm  signals,  and 

as  final-arm  signals,  and  E  ana  E^  as  the  fire  signals.  The  subscripts 
A  and  B  refer  to  the  channel.  Fuzing  success  as  the  equation  above 

indicates  requires  both  a  pre-arm  and  a  final-arm  signal  on  either  channel  and 
a  fire  signal  from  either  channel. 

The  sequenced  outputs  are  generated  by  the  times  of  arrival  of  external 
signals  W,  battery  initiation,  and  X^,  Y  and  Z.  The  expected 

sequence  of  operation  is  (1)  the  receipt  of  signal  W  of  time  1  energizing 
squib  switches  S  and  S  closing  the  six  pairs  of  normally  open 
lk  *B 

switch  contacts  on  all  output  lines;  (2)  actuation  of  batteries  and 

at  time  1  simultaneous  with  the  receipt  of  signal  W;  (3)  function  of 
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603  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 

OPERATOR  FILE  -  G01  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 

KIND  FILE  -  602  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 

RUN  NUMBER  1 

PM  I N  ~0 . OOOOE  +  OO 

NEW  -  Ot  INTER  «  0  >  SAVE  "  0,  MXDIST  »  3000 

FIRST  ~  10000?  LAST.  "  10000?  TRACE  "  2.00000 


FINAL  EVENT  TABLE  (INFINITY  *  1) 

SIGNALS  AND  THEIR  VALUES 


PROBABILITY  20  30 


0.0018056317  1  1 
0.0298738996  1  0 
0.9683204687  0  0 


TOTAL  PROBABILITY  -  1.0000000000 

TOTAL  ERROR  -  0.0000000000 


INDIVIDUAL  SIGNAL  PROBABILITY  DISTRIBUTIONS 
VAL.  20  30 


0  0 . 9683204687  0.9981943683 
1  0.0316795313  0.0018056317 


CPU  TIME  =•  0:00:00.35 
DIRECT  I/O  COUNT  -  6 
ELAPSED  TIME  ~  00  $ 00  :  01  *72 


FIGURE  60  G03  DATA  FOR  PUMP  SYSTEM  AVAILABILITY 
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FIGURE  61  WEAPON  FUZING  SYSTEM 


accelerometers  and  X^;  (4)  the  receipt  of  signal  Y;  (5)  the  receipt 
of  signal  Z.  Figure  62  defines  the  values  which  the  signals  may  take  in  the 
GO  model  of  this  system. 


VALUE  DEFINITION 


0  All  time  prior  to  arrival  of  signal  W. 


1  Time  instant  at  which  signal  W  should  normally  arrive. 


2  Time  instant  between  the  arrival  of  signal  W,  X  ,  and  X_, . 

A  R 


3  Time  instant  at  which  signal  X  and  X  should  normally  arrive. 

n.  D 


4  Time  instant  between  arrival  of  signals  XA ,  X^ ,  and  Y. 

A  B 


5  Time  instant  at  which  signal  Y  should  normally  arrive. 


6  Time  instant  between  arrival  of  signals  Y  and  Z. 


7  Time  instant  at  which  signal  Z  should  normally  arrive. 


8  Final  time  point  of  interest. 


15  Never  (i.e.,  at  infinite  time). 


FIGURE  62  WEAPON  FUZING  SYSTEM  SIGNAL 
VALUE  DEFINITION  AND  TIME  REFERENCE 
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A  GO  model  of  the  weapon  fuzing  system  is  shown  in  Figure  63.  Supertype 
100  was  defined  as  shown  in  Figure  64  to  represent  the  ubiquitous  pairs  of 
normally  open  switch  contacts.  Signal  45  is  the  final  output  signal.  A 
reliable  fuzing  system  is  represented  as  event  45^,  signal  45  taking  value  7. 
The  events  45^,  45,.,  or  45^,  represent  premature  weapon  detonations  and  are 
safety  problems  of  varying  severity.  Event  45^  represents  a  late  detonation. 
The  event  45  ^  represents  the  failure  of  the  fuzing  system. 

Figure  65  depicts  the  G01  output  for  this  system  model.  The  numerous 
uses  of  supertype  100  are  recorded  as  is  the  system  configuration. 
Seventy-two  operators  are  used.  Signal  45  is  the  only  output  signal 
requested . 

Figure  66  records  the  probability  input  data  for  each  component  class 
(kind).  The  probability  mass  functions  showing  the  probabilities  of  arrival 
of  the  external  input  signals  W,  X,  Y,  and  Z  are  shown.  Data  for  the  kind  12 
type  9  operator  representing  the  sprytron  which  requires  a  precise  combination 
of  the  times  of  arrival  of  its  two  input  signals  is  also  shown. 

The  G03  output  data  of  Figure  67  records  that  there  are  six  possible 
system  events.  The  most  likely  event,  45?,  indicates  a  system  reliability  of 
0.993547.  The  probability  of  system  failure,  45^->  is  0.005291.  ^The 
probabilities  of  occurrence  of  the  three  premature  events  range  from  lxl(^  to 
9.9x10  .  The  late  detonation  event,  450,  occurs  with  probability  1x10  . 

o 

This  example  has  portrayed  the  application  of  the  GO  methodology  to 
simultaneously  analyze  both  the  safety  and  the  reliability  of  a  generic  weapon 
fuzing  system.  The  dependent  effects  of  all  component  operational  modes  and 
all  external  input  signals  are  combined  and  used  to  characterize  weapon 
performance.  The  dependent  effects  simultaneously  influencing  both  safety  and 
reliability  are  properly  incorporated. 

Example  7  -  Communication  Network  Analysis 

The  purpose  of  this  example  is  to  demonstrate  the  application  of  the  KSC 
GO  methodology  to  analyze  the  probability  of  information  flow  in  a  simple 
communication  network.  The  communication  network  to  be  analyzed  is  one 
treated  by  J.  deMercado,  et.  al. ,  in  IEEE  Transactions  on  Reliability,  Volume 
R-25,  June  1976,  pp.  71-76. 

The  network  is  shown  in  Figure  68.  The  object  of  the  analysis  is  to 
determine  the  probability  of  transmitting  information  from  node  s  to  node  t 
given  the  existing  links  between  nodes  and  the  probabilities  of  proper 
information  transmission  on  the  links.  Note  that  the  direction  of  information 
flow  is  shown  with  arrowheads.  On  all  links  except  ac  and  be  the  flow  is 
uni-directional.  In  this  system  the  nodes  are  perfect. 

The  network  is  transformed  into  the  block  diagram  of  Figure  69  with  the 
links  shown  as  blocks  and  the  nodes  as  circles. 
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FIGURE  63  WEAPON  FUZING  SYSTEM  GO  MODEL 


FIGURE  64  SUPERTYPE  REPRESENTING  PAIR  OF 
NORMALLY  OPEN  SWITCH  CONTACTS 
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GO  1 

( KSCGO  t  MAX  VERSION  1.0) 

RUN 

ON 

1-N0V-82 

AT 

16: 07: 49 

COPYRIGHT  <C>  1982  b\<  KAMAN  SCIENCES  CORPORATION 

EX3  - 

GO  1 

INF  IN 

»  15 f  VALUES  =  16 r  BIAS  » 

750r 

OPS  =  1 

f  s 

IGNALS  -  1 r 

ERRORS  -  25 

OP 

DATA 

XX  XX 

100  -1  101  102  103  201  1001 

$ 

X  X  X  Y 

6  1001  101  102  1  $  SWITCH  A 

XXX  Y 

6  1001  101  103  2  $  SWITCH  B 

XX  XY 

20212  201  $  OR  GATE 

1 

END  $ 

— 

END  OF  SUPER  TYPE  100 

1 

5  6  1  $  START  A 

1  1  1  5  $  BATTERY  A 

“jr 

5  7  4  $  START  B 

A 

5  8  2  $  INPUT  X-A 

5 

5  8  3  $  INPUT  X-B 

/. 

1  1  4  6  $  BATTERY  B 

$$$35 

100  052373$  A1 

7 

( L.  =  1  )  6  3  5 

2 

751 

$$  A 1 

SWITCH  A 

8 

(L-l)  635 

3 

752 

$$  A 1 

SWITCH  B 

9 

<L=1>  2  0  2 

751 

752 

7  $$ 

A 1 

OR  GATE 

$  $  1  $ 

100062383$  B1 

10 

<  L  —  1  )  6  3  6 

9 

753 

$$  B 1 

SWITCH  A 

11 

<  L~  1  >  6  3  6 

3 

754 

$$  B 1 

SWITCH  B 

12 

(L  =  l)  202 

753 

75  4 

8  $$ 

B  J 

OR  GATE 

13 

1279$  RESISTOR  A1 

14 

3  4  9  11  $  S2 A 

15 

1  2  8  10  $  RESISTOR  B1 

16 

3  4  10  12  $  S2B 

$$$$ 

100  0  7  11  12  13  3  $  A 2 

17 

(  L  =  1  )  6  3  7 

11 

755 

$$  A2 

SWITCH  A 

13 

(L-l)  6  3  7 

12 

756 

$$  A2 

SWITCH  B 

19 

( L  =  1 )  2  0  2 

755 

756 

13  $$ 

A  2 

OR  GATE 

$$$« 

100  0  8  11  12  14  3  $  B2 

20 

(L-l)  6  3  8 

1 1 

757 

$$  B2 

SWITCH  A 

21 

(L-l )  6  3.8 

12 

758 

$$  B2 

SWITCH  B 

22 

>'L  =  1)  2  0  2 

757 

758 

14  $$ 

B2 

OR  GATE 

23 

5  9  15  $  INPUT  Y 

24 

1  2  15  16  $  RESISTOR  A2 

25 

12  15  17  $  RESISTOR  B2 

2  6 

3  4  16  18  $  S3 A 

2  7 

3  4  17  19  $  S3B 

$$»» 

100  0  13  18  19  20  3  $  A3 

28 

(L-l)  6  3  13 

18 

759 

$$  A3 

SWITCH  A 

')  o 

(L-l)  6  3  13 

19 

760 

$$  A3 

SWITCH  B 

30 

(L-l )  202 

759 

760 

20  $$ 

A3 

OR  GATE 

FIGURE  65  G01  OUTPUT  FOR  WEAPON  FUZING  SYSTEM 
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42 

2  0  2  24  25  26  $  OR  GATE 

43 

5  10  27  $  INPUT  Z 

44 

10  0  2  26  27  28  $ 

AND  GATE 

4  5 

5  11  29  $  INPUT  W 

46 

1  2  29  30  $  RESISTOR  A3 

4  7 

1  2  29  31  $  RESISTOR  B3 

48 

3  4  30  3  2  $  S 1 A 

4  ? 

3  4  31  33  $  SIB  ' 

100  0  7  32  33  34  3 

$  CA 

50 

( L.  =  1 )  6  3 

7 

32 

767 

$$  CA 

SWITCH  A 

51 

<L-1>  6  3 

7 

33 

768 

$$  CA 

SWITCH  B 

52 

(L=l)  2  0 

9 

767 

768 

34  $$ 

CA 

OR  GATE 

$*53 

100  0  20  32  33  35 

3  $  DA 

53 

<L=1)  6  3 

20 

32 

769 

$$  DA 

SWITCH  A 

54 

<  L  -•  1 )  6  3 

20 

33 

770 

$$  DA 

SWITCH  B 

55 

<  L-l )  2  0 

9 

769 

770 

35  $$ 

DA 

OR  GATE 

$$54 

100  0  28  32  33  36 

3  $  EA 

56 

(L-l)  6  3 

28 

32 

771 

$$  EA 

SWITCH  A 

57 

( L-l )  6  3 

28 

33 

772 

$$  EA 

SWITCH  B 

58 

(L  =  l)  2  0 

2 

771 

772 

36  $$ 

EA 

OR  GATE 

$$59 

100  0  8  32  33  39  3 

$  CB 

59 

(L-l)  6  3 

8 

32 

773 

$$  CB 

SWITCH  A 

60 

( L.  “•  1  )  6  3 

8 

33 

774 

$$  CB 

SWITCH  B 

61 

( L  - 1 )  2  0 

9 

773 

774 

39  $$ 

CB 

OR  GATE 

$$42 

100  0  23  32  33  38 

3  $  DB 

62 

<L=1)  6  3 

23 

32 

775 

$$  DB 

SWITCH  A 

63 

(L-l)  6  3 

23 

33 

776 

$$  DB 

SWITCH  B 

64 

( L=1 )  2  0 

p 

775 

776 

38  $$ 

DB 

OR  GATE 

$$45 

100  0  28  32  33  37 

3  $  EB 

65 

( L  =  1  )  6  3 

28 

32 

777 

$$  EB 

SWITCH  A 

66 

(L.-1)  6  3 

28 

33 

778 

$$  EB 

SWITCH  B 

67 

( L= 1 )  2  0 

2 

777 

778 

37  $$ 

EB 

OR  GATE 

68 

2  0  2  36  37  44  $  FIRE 

69 

10  0  2  34  35  40  $ 

CA  AND 

DA 

70 

10  0  2  38  39  41  $ 

CB  AND 

DB 

71 

2  0  2  40  41  42  $  ARM 

72 

9  12  42  44  45  $  SPRYTRON 

//7Z 

0  45  $  FINAL  SIGNAL 

FIGURE. 65  (CONTINUED) 
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FIGURE  65  (CONTINUED) 
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FIGURE  65  (CONTINUED) 
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FIGURE  66  G02  OUTPUT  FOR  WEAPON  FUZING  SYSTEM 


G03  (KSCGO?  VAX  VERSION  1,0)  RUN  ON  1-N0V-82  AT  16*,07:58 
COPYRIGHT  (C)  1982  b u  KAMAN  SCIENCES  CORPORATION 


EX3  -  GO 3 


OPERATOR  FILE  -  EX3  -  G01 


KIND  FILE  -  EX3  -  G02 

RUN  NUMBER  1 

PM  IN  ~  1 , 0000E-08 

NEW  -  Of  INTER  =  If  SAVE  «  Of  MXDIST  -  3000 

FIRST  -  10000;  LAST  ~  10000?  TRACE  -  2,00000 


FINAL  EVENT  TABLE  (INFINITY  -  15) 


SIGNALS  AND  THEIR  VALUES 


PROBABILITY  45 

0,0000014703  4 
0,0000145555  5 
0,0000986113  6 
0,0010040127  8 
0,0052914723  15 
0,9935471604  7 


TOTAL  PROBABILITY  ~  0.9999572829 

TOTAL  ERROR  =  0,0000427171 


INDIVIDUAL  SIGNAL  PROBABILITY  DISTRIBUTIONS 
VAL.  45 

4  0.0000014703 

5  0.0000145555 

6  0.0000986118 

7  0.9935471604 

3  0,0010040127 

15  0.0052914723 


CPU  TIME  -  0:00:il,31 
DIRECT  I/O  COUNT  =  18 
ELAPSED  TIME  -  00  *.  00  J  11.99 


FIGURE  67  G03  OUTPUT  FOR  WEAPON  FUZING  SYSTEM 


88 


89 


FIGURE  70  GO  CHART  OF  NETWORK  GRAPH 


We  now  develop  a  GO  model  of  the  network  using  the  standard  symbols.  The 
GO  model  is  shown  as  Figure  70.  Figures  68,  69,  and  70,  are  shown  on  the  same 
page  to  show  the  relationship  of  the  GO  model  to  the  network  and  its  block 
diagram. 

The  outputs  from  programs  G01,  G02,  and  G03,  shown  in  Figures  71,  72,  and 
73,  document  the  network  model,  the  transmission  probability  data,  and  the 
system  transmission  probability.  The  probability  of  successfully  transmitting 
information  from  node  s  to  node  t  with  the  link  probabilities  specified  is 
0.8307072. 

More  sophisticated  treatment  of  communication  systems  involving  node 
uncertainties  and  additional  two-way  transmission  links  is  discussed  in  the 
KSC  GO  Model  Development  Manual. 


G01 

<KS 

CG0  ?  MAX  VERSION  1.0)  RUN  ON  5-N0V-82  AT  08  3  23  3 10 

COPYRIGHT  (C)  3.982  bu  K A M A N  SCIENCES  CORPORATION 

G01  0 

QMMUNICATIQN  NETWORK  ANALYSIS 

INF  IN 

— 

1,  VALUES  -  2  •>  BIAS  -  750.  OPS  *  1.  SIGNALS  •••  Jr 

ERRORS  »  25 

OP 

DATA 
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100  1  $  START 
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9 
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20  $  FINAL  SIGNAL 

FIGURE  71  GOI  COMMUNICATION  NETWORK  ANALYSIS 
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GO 2  ( KSCGO  >  VAX  VERSION  1,0)  RUN  ON  5-N0V-82  AT  08123:15 

COPYRIGHT  (C)  1982  by  KAMAN  SCIENCES  CORPORATION 

G02  COMMUNICATION  NETWORK  ANALYSIS 

PERF  0?  MXSIZE  -  20  48 

OPERATOR  FILE  -  GDI  COMMUNICATION  NETWORK  ANALYSIS 

RECORD  KIND  DATA 


1  1  1  0,75  0,25  $  SD 

2  2  1  0,60  0,40  %  DC 1 

3  3  1  0,50  0,50  $  DC 2 

4  4  1  0.90  0,10  $  SA. 

5  5  1  0,70  0.30  *  AC 

6  6  1  0.50  0.50  $  AB2 

7  7  1  0.80  0.20  $  AB1 

8  8  1  0,90  0,10  $  BC 

9  9  1  0.70  0.30  $  BT 

10  10  1  0,60  0.40  $  CT 

11  100  5  1  0  1,  $  START 


USE  SUMMARY  TABLE,  ENTRY  KIHD/TYPE< FREQUENCY ) 

(FREQUENCY  IS  NEGATIVE  FOR  PERFECT  KINDS.) 

1/  1(  1)  2/  1(  1)  3/  1(  1)  4/  1(  1)  5/  1<  1) 

6/  1C  1)  7/  1(  1)  8/  1  (  1)  9/  1(  1)  10/  1(  1) 

100/  5 (  1) 

NUMBER  OF  KINDS  INPUT -  11 

NUMBER  USED  -  NONPERFECT —  11 

NUMBER  USED  -  PERFECT -  0 


1  FILE  RECORDS  WRITTEN  FOR  20  OPERATORS. 

CPU  TIME  -  0:00‘.00.77 
DIRECT  I/O  COUNT  =  15 
ELAPSED  TIME  =-  00100:03.57 


FIGURE  72  G02  COMMUNICATION  NETWORK  ANALYSIS 
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GD3  ( KSCGO  t  VAX  VERSION  1,0)  RUN  ON  5-N0V-82  AT  08:23: 20 
COPYRIGHT  ( C )  1982  by  KAMAN  SCIENCES  CORPORATION 

G 0 3  COMMUNICATION  NETWORK  ANALYSIS 

OPERATOR  FILF  —  G01  COMMUNICATION  NETWORK  ANALYSIS 


KIND  FILE  -  G02  COMMUNICATION  NETWORK  ANALYSIS 

RUN  NUMBER  1 

PM I N  =0  «  OQOOE  +  OO 

NEW  =  Or  INTER  =  0.  SAVE  -  Or  MXDIST  *  3000 

FIRST  “  1 0000  7  LAST  -  lOOOOr  TRACE  ~  2.00000 


FINAL  EVENT  TABLE  (INFINITY  ~  1) 

SIGNALS  AND  THEIR  VALUES 


PROBABILITY  20 

0.1692928000  1 

0,8307072000  0 


TOTAL  PROBABILITY  =  1,0000000000 

TOTAL  ERROR  =  0,0000000000 


INDIVIDUAL.  SIGNAL  PROBABILITY  DISTRIBUTIONS 
VAL.  20 


0  0.8307072000 

1  0.1692928000 


CPU  TIME  -=  0:00:00,39 
DIRECT  I/O  COUNT  =  6 
ELAPSED  TIME  ~  00  ,*00 101,11 


FIGURE  73  G03  COMMUNICATION  NETWORK  ANALYSIS 
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CHAPTER  5 
FAULT  FINDER 


Introduction 

The  KSC  Fault  Finder  programs  are  auxiliary  to  the  basic  KSC  GO  programs 
defined  and  exemplified  in  earlier  chapters.  The  purpose  of  the  Fault  Finder 
is  to  answer  the  question,  "What  causes  such  and  such  an  event  to  occur?" 
Usually  the  referenced  event  is  a  system  failure  which  is  caused  by  the 
failures  of  single  components  or  the  simultaneous  failures  of  two  or  more 
components.  Often  there  are  many  such  failure  combinations  which  could  cause 
a  selected  system  failure  event  to  occur.  The  Fault  Finder  programs 
explicitly  identify  and  manipulate  these  fault  sets. 

The  term  "fault  set"  was  deliberately  selected  to  reference  these 
component  failure  combinations  causing  system  failures,  rather  than  "cut 
sets",  because  of  the  inherently  more  general  nature  of  a  GO  model  over 
a  fault  tree  model.  Components  modeled  using  the  GO  methodology  are  not 
restricted  to  binary  states,  e.g.,  good,  bad,  as  are  the  elements  of  a 
fault  tree.  Consequently  to  differentiate  between  the  more  general 
faults  which  might  be  defined  for  the  operational  states  of  components 
in  a  GO  model  and  those  of  the  more  restricted  two-state  formulation  of 
a  fault  tree,  we  have  chosen  the  term  fault  set,  rather  than  cut  set,  to 
describe  the  component  or  element  failure  combinations  which  cause 
system  failures. 

Fault  Finder  Example 

The  particular  event  —  known  as  the  "selected  event"  —  is  a  term,  or 
the  logical  union  of  several  terms,  of  the  final  distribution  produced  by  G03. 
The  selected  event  is  defined  by  the  user.  The  selected  event  in  most  cases 
is  a  system  failure,  but  it  may  be  any  G03  output  event  or  combination  of  such 
events . 

To  introduce  you  to  the  Fault  Finder  capability  we  will  use  the  model  of 
the  alarm  system  previously  discussed  as  example  4  in  Chapter  4.  We  reproduce 
here  for  convenience  the  G03  output  of  the  alarm  system  GO  model  as  Figure  74. 
There  are  two  system  failure  events.  These  are  1009,  representing  an  alarm 
system  failure,  and  100q,  representing  an  alarm  system  premature.  We  will 
execute  the  Fault  Finder  to  find  the  component  failure  modes  which  cause  each 
of  these  events  to  occur.  A  separate  run  will  be  made  for  each  case.  The 
selected  event  in  the  first  case  will  be  100^  entered  in  the  form 
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100  2  $ 


G03  ( KSCGO  ;  VAX  VERSION  1.0)  RUN  ON  22-0CT-82  AT  16MBtlO 

COPYRIGHT  <C>  1982  b'j  KAMAN  SCIENCES  CORPORATION 

G03  DATA  FOR  ALARM  SYSTEM 

OPERATOR  FILE  -  G01  DATA  FOR  ALARM  SYSTEM 

KIND  FILE  -  G02  DATA  FOR  ALARM  SYSTEM 

RUN  NUMBER  1 

PMIN  “0 . OOOOE+OO 

NEW  -  0;  INTER  =•=  0»  SAME  -  0»  MXDIST  -  3000 
FIRST  =  100007  LAST  -  10000;  TRACE  «  2.00000 


FINAL  EVENT  TABLE  (INFINITY  «  2) 

SIGNALS  AND  THEIR  VALUES 


PROBABILITY  10  20  100 


0.0000076721 
0.0000076721 
0 . 0000946688 
0.0001818926 
0.0001818926 
0.0211465091 
0.0261715023 
0.0261715023 
0.9260366882 


0  2  0 
2  0  0 
0  0  0 
0  1  0 
1  0  0 
2  2  2 
2  1  1 
1  2  1 
1  1  1 


TOTAL  PROBABILITY  -  1.0000000000 

TOTAL  ERROR  -  0.0000000000 


INDIVIDUAL  SIGNAL  P 


VAL.  10 


0  0.0002842335 

1  0.9523900830 

2  0.0473256835 


ROBABILITY  PIS 
-  20 

0.0002842335 

0.9523900830 

0.0473256835 


TRIBUTIONS 

100 

0.0004737982 

0.9783796927 

0.0211465091 


CPU  TIME  «  0 tOO: 00. 58 
DIRECT  I/O  COUNT  -  7 
ELAPSED  TIME  ~  00 5 00 J 01. 22 


FIGURE  74  G03  OUTPUT  FOR  ALARM  SYSTEM 
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in  the  input  data  file  for  program  FF1.  In  the  second  case  the  selected  event 
will  be 


100  0  $  . 

Before  proceeding  we  define  the  use  of  critical  mode  codes  for  each  GO 
operator.  These  are  the  use  of  numbers  0,  1,  2,  and  3,  to  define  the 
operational  states  of  operators.  The  standard  critical  mode  code 
definitions  are  shown  at  the  top  of  Figure  75. 

Most  GO  operators  are  given  default  values  for  their  operational  states 
as  shown  in  the  bottom  half  of  Figure  75.  For  example  a  type  1  operator  has 
two  operational  states,  good  and  bad.  Normally  the  good  state  is  considered  a 
success  and  is  given  a  critical  mode  code  of  0.  Similarly  the  bad  state  is 
usually  considered  a  failure  and  is  given  a  critical  mode  code  of  1.  If  this 
is  what  the  user  intends,  no  data  need  be  entered  because  default  mode  codes 
of  0  and  1  have  been  entered  for  these  two  operational  states.  If  the  user 
wants  to  enter  the  mode  .codes  explicitly,  or  desires  that  they  be  different 
than  the  default  mode  codes,  this  is  done  in  the  manner  shown  in  Figure  75. 
For  a  type  1  operator,  the  data  in  FF2  is  entered  as 

K  1  M2  $ 

where  and  are  the  mode  codes  for  the  two  operational  states  of  the 
type  1  operator.  Only  the  codes  0,  1,  2,  and  3  are  permissable.  The  default 
values  for  the  type  1  are  M^=0,  M2=l. 

Operators  of  type  2,  9,  10,  11,  14,  15,  do  not  require  critical  mode  code 
definitions  because  their  operation  is  logically  perfect  —  i.e.,  they 
represent  and  perform  logical,  rather  than  functional,  operations. 

Figure  76  documents  that  the  selected  event  —  the  system  failure  event 
for  which  fault  sets  are  sought  —  is  100~.  The  FF1  manipulation  then  alters 
the  distribution  file  formerly  created  Dy  G03  with  the  parameter  SAVE=1, 
eliminating  all  terms  which  do  not  lead  to  the  selected  event.  In  the  process 
it  also  deletes  perfect  operators  from  consideration. 

Now  program  FF2  is  executed  to  find  the  fault  sets  by  their  order,  i.e., 
the  number  of  components  whose  simultaneous  failure  cause  the  selected 
event.  The  user  has  the  option  to  override  the  default  critical  mode  code 
values.  In  particular,  data  to  specify  the  failure  modes  for  type  5  operators 
is  almost  always  required. 

The  output  data  for  the  FF2  run  to  find  the  fault  sets  causing  system 
failure  event  10CL  is  shown  in  Figure  77.  The  user-defined  critical  mode 
codes  for  kind  1  type  5  and  kind  4  type  5  are  shown  in  essentially  the  same 
manner  as  input  in  G02.  The  line  entry 

1  5  2  0  1  $ 
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I - 

0  —  SUCCESS  MODE 

1  --  FAILURE  MODE 

2  —  PREMATURE  MODE 


3  —  VARIABLE  MODE 


KIND 

TYPE* 

CRITICAL 

MODE 

CODE 

DEFAULTS 

K 

1 

Mx  M2 

0  1 

K 

3 

M1  M2  M3 

0  1  2 

K 

4 

m  Mr..Mm 

0...0 

m 

K 

5 

n  M^ . . .M 

d 

o 

• 

• 

# 

o 

K 

6 

M,  M0  M0 

0  1  2 

K 

7 

M1  M3 

0  1  2 

K 

8 

n  M, . . .M 

1  n 

°-°n 

K 

12 

n  Mr..M 

K 

13 

n  Mr..M 

*TYPES 

2,  9,  10, 

11,  14,  &  15  unnecessary. 

FIGURE  75 

FF2  CRITICAL  MODE  DEFINITION  DATA  INPUT  SUMMARY 
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FF1  INPUT  DATA  FOR  ALARM  SYSTEM 

MODEL?  GO  1  DATA  FOR  ALARM  SYSTEM 
KINDS?  G02  DATA  FOR  ALARM  SYSTEM 

I NTER-0  t  PRUNE-0 * OOOOOOF TOO 

SELECTED  EVENT  -  SIGNAL  NUMBER ( VALUE ) 

1.  100(  2) 

A  PERFECT  OPS  DELETED 
2  7  11  15 

11  OPS  LEFT  IN.  TREE 

1  3  A  5  6  8  9  10  12  13 


1  OP  RECORDS  IN  FAULT  FILE  (FILE  AQ) 


FIGURE  76  FF1  OUTPUT  FOR  ALARM  SYSTEM 
SELECTED  EVENT  1002 


.9,8 


FF2  DATA  FOR  ALARM  SYSTEM 

MODEL:  GO  1  DATA  FOR  ALARM  SYSTEM 
KINDS:  G02  DATA  FOR  ALARM  SYSTEM 

SELECTED  EVENTS:  SIGNAL  NUMBER < VALU E ) 

1,  100(  2) 

INTER-  1*  FIRST*  Oj  LAST*  At  11  OPS 

USER-DEFINED  CRITICAL  MODE'S 

1  5  2  0  1  $ 

4  5  2  0  1  $ 

-  START  OF  O-ORDER  FAULTS  - 

TREE  VANISHED  AT  OP  10,  MO  O-ORDER  FAULTS, 
-  END  OF  O-ORDER  FAULTS  - 

-  START  OF  1 -ORDER  FAULTS  . 

1-ORDER  FAULT  SETS 

SET  OP (MODE)  NAME 
1  ,  1(1)  MAIN  BAT 

-  END  OF  1 -ORDER  FAULTS  -  ' 


FIGURE  77  FF2  OUTPUT  FAULT  SETS  CAUSING  SYSTEM 

FAILURE  EVENT  1002 
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-  START  OF  2 "ORDER  FAULTS  —  - . . 

2-ORDER  F AULT  SETS 


SET 

OP (MODE) 

NAME 

OP (MODE) 

NAME 

1  . 

'1(1) 

C 

ENSOR  2 

5(1) 

SENSOR  3 

2  . 

9(1.) 

A 

D  E  S  LI  I T 

1 3  ( 1  ) 

B 

DESUIT 

3. 

9(1) 

A 

DESUIT 

14(1) 

B 

DEALAR 

4  ♦ 

9(1) 

A 

DESUIT 

12(1) 

B 

DEALAR 

5  * 

10(1) 

A 

DEAL.AR 

13(1) 

B 

DESUIT 

Cj  * 

10(1) 

A 

DEALAR 

14(1) 

B 

DEALAR 

7 

* 

10(1) 

A 

DEALAR 

12(1) 

B 

DEALAR 

o 

Vw*  ♦ 

8(1) 

A 

DEALAR 

13(1) 

B 

DESUIT 

9  ♦ 

8(1) 

A 

DEALAR 

14(1) 

B 

DEALAR 

1 0 . 

3(1) 

A 

DEALAR 

12(1) 

B 

DEALAR 

. .  END  OF  2-ORDER  F 'AULTS  - 

-  START  OF  3-ORDER  FAULTS  - 

3-ORDER  FAULT  SETS 


SET 

OP (MODE) 

NAME 

OP (MODE) 

NAME 

OP ( MODE ) 

... 

NAME 

1  ♦ 

3(1) 

SENSOR 

t 

4  ( 1  ) 

SENSOR 

p 

6(1) 

C 

ENSOR  4 

o 

* 

3(1) 

SENSOR 

1 

4(1) 

SENSOR 

n 

13(1) 

B 

BESWI! 

3  ♦ 

3(1) 

SENSOR 

1 

4(1) 

SENSOR 

9 

14(1) 

B 

DEALAR 

4  ♦ 

3(1) 

SENSOR 

1 

4(1) 

SENSOR 

*■* 

12(1) 

B 

DEALAR 

3  ♦ 

3(1) 

SENSOR 

1 

5(1  ) 

SENSOR 

6(1) 

S 

ENSOR  4 

6  ♦ 

3(1) 

SENSOR 

1 

5(1) 

SENSOR 

•? 

13(1) 

B 

DESUIT 

7  ♦ 

3(1) 

SENSOR 

1 

5(1) 

SENSOR 

3 

1  4  (  1.  ) 

B 

DEALAR 

8  ♦ 

3(1) 

SENSOR 

1 

5(1  ) 

SENSOR- 

3 

12(1) 

B 

DEALAR 

9  ♦ 

4(1) 

SENSOR 

2 

6(1) 

SENSOR 

4 

9(1) 

A 

DESUIT 

10* 

4(1) 

SENSOR- 

p 

6(1) 

SENSOR 

•1 

10(1) 

A 

DEALAR 

1 1  * 

4(1) 

SENSOR 

7 

6(1) 

SENSOR 

4 

8(1) 

A 

DEALAR 

1 2  ♦ 

5(1) 

SENSOR- 

3 

6  (  1  ) 

SENSOR 

4 

9  (  1  ) 

A 

HE SUIT 

1  3  ♦ 

5(1) 

SENSOR 

3 

6(1) 

SENSOR 

4 

10(1) 

A 

DEALAR 

14 ♦ 

5(1) 

SENSOR 

3 

6(1) 

SENSOR 

4 

8(1) 

A 

DEALAR 

END  OF  3-ORDER  FAULTS  - 


FIGURE  77  (CONTINUED) 
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FIGURE  77  (CONTINUED) 


means  that  kind  l,  type  5,  has  2  values.  The  first  value  is  treated  as  a 
success  (critical  mode  code  of  0)  and  the  second  value  is  considered  a  failure 
(critical  mode  code  of  1).  The  reader  should  refer  back  to  Figure  52,  G02 
Output  For  Alarm  System,  to  verify  the  intent  in  this  model  to  treat  the  first 
value  of  0  generated  by  this  type  5  operator  with  probability  0.98  as  the 
success  mode,  and  the  second  value  generated,  2,  with  probability  0.02,  as  the 
failure  mode. 

Figure  77  then  records  one  first-order  failure.  It  is  operator  //l,  the 
main  battery,  in  a  failure  mode  which  will,  by  itself,  cause  system  failure 
event  100?.  This  information  is  recorded  in  the  form 

1(1)  MAIN  BAT 

where  the  first  "1"  is  the  operator  number,  and  the  second  M1M,  in 
parentheses,  is  the  critical  mode  code  and  eight  characters  of  the  descriptor 
are  printed,  "MAIN  BAT". 

The  printout  also  shows  that  there  are  ten  second-order  fault  sets  and  14 
third-order  sets  which  cause  the  system  failure  event  100^.  The  reader  may 
want  to  convince  himself  of'  the  validity  of  these  fault  sets  by  referencing 
Figures  49  and  50  of  Chapter  4. 

To  conclude  the  FF2  printout  a  summary  table  lists  each  operator  which 
appeared  in  a  fault  set  with  the  frequency  of  occurrence  in  the  various  set 
orders . 

Using  the  identical  model,  but  choosing  the  selected  event  to  be  100n,  a 
system  premature,  the  fault  sets  of  Figure  78  were  generated.  Figure  78 
records  that  there  are  five  second-order  combinations  of  component  prematures 
(critical  mode  2)  which  can  cause  a  system  premature.  (Again  the  reader  may 
want  to  consider  the  physical  configuration  to  convince  himself  that  the 
various  combinations  of  sensor  prematures  will  cause  a  system  premature  by 
referencing  Figures  49  and  50. 

To  conclude,  the  Fault  Finder  capability  is  a  powerful  technique  to 
insure  the  validity  of  the  GO  model,  to  identify  major  contributors  to  system 
failure,  and  to  consider  modifications  to  enhance  system  performance.  Further 
information  about  the  Fault  Finder  can  be  found  in  the  documents  KSC  GO 
Fundamentals  and  the  KSC  GO  Reference  Manual. 
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—  . *  1  '  1  1,1 "  F  -  - . .  |  ■  .  - 

FF2  DATA  FOR  ALARM  SYSTEM 

MODEL:  GOl  DATA  FOR  ALARM  SYSTEM 
KINDS:  G02  DATA  FOR  ALARM  SYSTEM 

SELECTED  EVENTS  t  SIGNAL  NUMBER < VALUE > 

1.  100<  0) 

INTER=  if  FIRST-  Of  LAST=  4,  11  OPS 

USER-DEFINED  CRITICAL  MODES 

1  5  2  0  1  $ 

4  5  2  0  1  $ 

-  START  OF  O-ORDER  FAULTS  - 

TREE  VANISHED  AT  OP  5  »  NO  O-ORDER  FAULTS  * 
-  END  OF  O-ORDER  FAULTS  - 

-  START  OF  1-ORDER  FAULTS  - 

TREE  VANISHED  AT  OP  6,  NO  1 -ORDER  FAULTS. 
-  END  OF  1-ORDER  FAULTS  - 


FIGURE  78 

FF2  OUTPUT  FAULT  SETS  CAUSING 
SYSTEM  PREMATURE  EVENT  100Q 
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-  START  OF  2-ORDER  FAULTS 

2-ORDER  FAULT  SETS 


SET 

OP (NODE) 

NANE 

OP (NODE) 

NANE 

_ 

1  . 

5(2) 

SENSOR 

3 

6(2) 

SENSOR 

4 

9 

<L  « 

4(2) 

SENSOR 

9 

6(2) 

SENSOR 

4 

3  * 

4(2) 

SENSOR 

9 

5(2) 

SENSOR 

V-J 

4  * 

3(2) 

SENSOR 

1 

5(2) 

SENSOR 

3 

5  ♦ 

3(2) 

SENSOR 

1 

4(2) 

SENSOR 

n 

-  END  OF  2-ORDER  FAULTS  - 

-  START  OF  3-ORDER  FAULTS  - 

TREE  VANISHED  AT  OP  6.  NO  3-ORDER  FAULTS. 

-  END  OF  3-ORDER  FAULTS  - 

-  START  OF  4-ORDER  FAULTS  - 

TREE  VANISHED  AT  OP  6.  NO  4-ORDER  FAULTS. 

-  END  OF  4-ORDER  FAULTS  - 

NO  HIGHER  ORDER  FAULT  SETS  EXIST. 

FREQUENCY  OF  OPERATOR  OCCURRENCES  IN  FAULT  SETS 

FAULT  SET  ORDER 


(  NANE 

) 

TYPE 

KIND 

(  NANE 

) 

NODE 

TOTAL 

l 

9 

3 

4 

3 

(SENSOR 

1  ) 

6 

3 

(SENSOR 

) 

9 

9 

jL. 

0 

9 

0 

0 

4 

(SENSOR 

2) 

6 

3 

(SENSOR 

) 

9 

3 

0 

3 

0 

0 

5 

(SENSOR 

3) 

6 

3 

(SENSOR 

) 

9 

JL_ 

3 

0 

3 

0 

0 

6 

(SENSOR 

4  ) 

6 

3 

(SENSOR 

) 

9 

9 

0 

2 

0 

0 

FIGURE  78|  (CONTINUED) 
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CHAPTER  6 
EFFECT  EVALUATION 


Introduction 

The  three  Effect  Evaluation  (EE)  programs,  EEL,  EE2,  and  EE3,  have  been 
created  to  provide  a  systematic  method  of  evaluating  the  effect  of  data 
uncertainties  upon  the  probabilities  associated  with  the  final  events  of  a  GO 
model.  The  employment  of  the  EE  programs  is  introduced  with  a  simple  example 
of  three  components  in  series. 

EE  Theory 

As  a  basis  for  discussion,  consider  the  GO  model  whose  GO  chart  is  shown 
below  in  Figure  79. 


FIGURE  79  GO  MODEL  FOR  EE  DISCUSSION 


Let  infinity  (never)  =  7. 

Let  the  kind  data  be  as  shown  in  Figure  80. 


50  5  3  2  .5  4  .3  7  .2 

30  3  .7  .2  .1 

10  1  .75  .25 


FIGURE  80  G02  DATA  FOR  EE  DISCUSSION 

Using  G01,  002,  and  G03  (or  a  simple  hand  calculation)  we  find 

that  signal  300  has  the  following  probability  distribution: 

VALUE  PROBABILITY 

0  .075 

4  .1575 

2  .2625 

7  .505 

£ =  1.0000 

We  focus  our  interest  in  the  event  that  signal  300  has  a  value  of  either 
2  or  4.  The  probability,  p,  of  this  event  is, 

p  =  0.2625  +  0.1575 
=  0.42 

Let  us  now  assume  that  the  probabilities  used  to  define  kinds  10  and  50 
are  not  fixed  but  rather  are  uncertain  -  that  is,  are  random  variables.  Our 
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problem  is  to  estimate  the  effect  of  these  uncertainties  upon  p  which,  of 
course,  now  becomes  a  random  variable  itself,  and  which  we  will  designate  by 
P  rather  than  p. 

The  ultimate  solution  would  be  to  find  the  exact  probability  distribution 
of  P  as  this  would  provide  all  possible  information  about  P  -  e.g.,  its 
mean,  its  variance,  probability  (P<0.9),  etc.  This  solution  would  require 
that  the  distributions  of  the  random  kind  probabilities  be  known,  that  the 
formula  expressing  P  as  a  function  of  these  probabilities  be  known,  and  that 
the  analytical  machinery  for  finding  the  required  distribution  be  available. 
Unfortunately  in  most  problems  of  real  interest  the  kind  probability 
distributions  are  not  known,  and  the  formula  is  almost  always  of  a  most 
formidable  nature,  at  best,  and  usually  requires  an  exorbitant  amount  of  labor 
to  obtain  if  it  can  be  obtained  at  all.  In  fact,  the  entire  GO  concept  is 
based  upon  the  idea  of  evaluating  this  function  without  knowing  it  explicitly. 
Consequently,  we  shall  set  our  sights  at  something  less  than  the  ultimate 
solution. 

What  we  settle  for  in  the  EE  procedure  are  estimates  of  the  mean  and 
variance  of  P  (these  will  be  symbolized  by  m  and  v  respectively) .  Using 
these  estimates  we  can  also  calculate  approximate  confidence  intervals  for  the 
mean  of  P. 

Let  us  symbolize  the  variable  kind  probabilities  by  P.  (the  uppercase 
letter  indicating  a  random  variable),  their  means  by  m.  ,  ancl  their  variances 
by  v..  Also  let  f  be  the  existing,  but  generally  unknown,  system  function 
which  relates  P  to  the  P_^  -  e.g.,  P  =  f  (P^  ,P^ » •  .  .  )  • 

The  basic  assumption  of  EE  is  that  f  is  sufficiently  "linear"  that 
reasonable  approximations  of  the  mean  and  variance  of  P  are  given  by 

m  =  f  (mpti^.  .  .  ) 

and 


1 


Note  that  G03  evaluates  the  function  f  for  specified  values  of  the  m. 
without  knowing  f  explicitly. 

The  partial  derivatives  in  the  formula  for  v  are  evaluated  by 
subtracting  a  small  positive  amount,  A  >  from  the  value  of  m,,  reevaluating 
f,  and  then  forming  a  difference  quotient  as  shown  below. 

f  (m^ , .  •  •  m_^ ,...)- f(m^,...  ,m_^— •  •  •  ) 

dm ^  ~~  m  -(m  -4) 

By  choosing  A  small  the  partial  derivatives  can  be  calculated  as  precisely  as 
desired.  The  partial  derivative  of  an  event  with  regard  to  changes  in  the 
kind  data  is  known  as  the  sensitivity  of  the  event  with  respect  to  kind  i. 
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Once  m  and  v  are  obtained,  several  methods  could  be  used  to  obtain 
approximate  confidence  intervals  for  the  mean  of  P.  Because  this  mean  is 
essentially  a  probability  we  use  a  method  due  to  Easterling.  In  this  method 
m  is  treated  as  an  estimate  of  a  binomial  proportion  which  was  hypothetically 
obtained  by  x  "pseudo  successes"  in  n  "pseudo  trials".  If  this  had  indeed 
been  the  case  we  would  estimate  the  proportion  mean  and  its  variance  by, 


m  =  —  and 
n 


m( 1-m) 


However,  we  have  already  obtained  estimates  for  m  and  v  and,  consequently, 
we  can  now  determine  n  and  x  by  solving  these  two  equations  to  obtain: 


n 


m( 1-m) 
v 


and  x  =  mn 


(In  practice  the  values  of  n  and  x  are  rounded  up  to  the  next  integer.) 
Using  standard  procedures  the  required  binomial  confidence  intervals  can  now 
be  calculated.  (To  do  so  we  use  an  algorithm  due  to  Burstein  and  Anderson  in 
a  series  of  articles  in  the  Journal  of  the  American  Statistical  Association; 
September  1967,  857-61;  December  1968,  1413-5;  and  September  1973,  581-4). 

If  there  are  k  variable  kinds,  the  function  f  must  be  evaluated  k+1 
times  -  once  to  find  m  and  once  to  find  each  of  the  k  sensitivities.  The 
entire  solution  as  outlined  above  can  be  carried  out  using  just  G01,  G02,  G03, 
and  some  hand  calculations.  In  a  large  problem  the  hand  bookkeeping  chores 
could  become  quite  burdensome  and  error-prone.  The  purpose  of  the  EE  programs 
is  simply  to  automate  the  entire  procedure. 

There  are  three  EE  programs  -  EE  1 ,  EE2 ,  and  EE3.  EE1 ,  which  is  executed 
after  a  G01  run,  is  similar  to  G02  and  preprocesses  the  kind  data.  EE2 ,  uses 
the  operator  and  kind  data  provided  by  G01  and  EE1 ,  and  evaluates  the  system 
k+1  times  (each  evaluation  using  logic  identical  to  that  in  G03) .  EE2 
calculates  the  sensitivity  of  every  elementary  final  event  with  respect  to 
each  variable  kind.  Finally,  EE3  calculates  the  required  estimates  and  bounds 
for  any  event  selected  by  the  user.  ‘  • 

When  evaluating  f  for  a  sensitivity  calculation  we  decrement  a  kind 
probability  by  A  •  Because  the  several  probabilities  associated  with  each 
kind  must  sum  to  unity,  this  means  that  one  or  more  of  the  other 
probabilities  must  be  incremented.  With  kind  data  from  two-state  operators 
(type  1  and  possibly  types  4,  5,  8,  and  12)  there  is  no  problem.  When  an 
operator  has  more  than  two  states  (types  3,  6,  7,  and  possibly  others)  the 
situation  is  less  clear.  We  have  chosen  the  convention  that  in  such  a  case 
only  two  of  the  several  kind  probabilities  will  be  altered  -  one  decremented 
by  A  and  the  other  incremented  by  A  •  The  one  to  be  decremented  will  be 
designated  by  G  and  the  other  one  by  B.  As  far  as  the  results  are 
concerned  it  is  immaterial  if  the  G  and  B  are  interchanged  because  if  this 
is  done,  the  signs  of  the  sensitivities  will  be  reversed,  but  in  the 
computation  of  v  the  sensitivities  are  squared.  However  to  avoid  potential 
problems  related  to  the  precision  of  the  computations,  it  seems  safer  to 
assign  G  to  the  larger  probability  (which  usually  represents  some 
"good"  state)  and  B  to  the  smaller. 
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The  selection  of  A  is  somewhat  arbitrary.  In  general  a 
smaller  A  gives  a  better  approximation  of  the  partial  derivative.  However, 
precision  limitations  require  that  the  resulting  differences  be  large  enough 
to  prevent  them  from  being  hidden  in  the  roundoff  noise.  Our  approach  is  to 
define  a  "delta  factor"  and  then  calculate  as  a  function  of  PMIN  as  follows: 

A  =  PMIN  x  delta  factor 

The  default  value  of  the  delta  factor  is  10,  but  it  may  be  set  to  another 
value  by  the  user. 

Let  us  now  return  to  our  example.  For  the  variable  kind  10  (type  1)  let 

represent  the  good  state  probability  and  the  dud  state  probability. 

Note  that  B  =  l.-G  Let  0.75  be  the  mean  of  G  and  let  its  variance 

be  0.0001.  iU  iU 

For  the  variable  kind  50  (type  5)  let  G  ~  represent  the  probability  of 

that  the  operator  signal  takes  the  value  2  ana  B  the  probability  of  that 

the  signal  generated  by  the  operator  takes  the  value  7  (thus  the  probability 

of  taking  the  value  4  will  remain  fixed  at  0.3).  In  this  case  we  see  that 

Br ^  =  1.  -  0.3  -  Grr,  =  0.7  -  Gcri.  Let  0.5  be  the  mean  of  G  n  and  let  its 
50.  ,  n  50  50  50 

variance  be  0.0375. 

This  model  is  sufficiently  simple  that  the  exact  formulas  for  the  final 
events  can  be  readily  found.  Let  300.  be  the  event  that  the  final  signal 
300  takes  on  the  value  i  and  let  p\300.)  be  its  probability.  Then,  in 
terms  of  G,  ^  and  G^~  (which  correspond  to  the  m.  in  the  earlier 
discussion),  we  have, 

P(300n)  =  0.1  G 
P(300p  =  0.7  G 
P(30CT)  =  0.21 
P (300^)  -  1.  - 

These  formulas  must  be  evaluated  three  times.  In  the  first  evaluation 
(the  "reference  run"  which  calculates  the  point  estimate  of  the  event 
probabilities)  we  replace  G  and  G^^  by  their  means  -  i.e.,  G^  =  0.75 
and  Gcn  0.5.  In  the  second  evaluation  (the  "sensitivity"  run  for  kind  10) 
we  use'  u  =  0.75  -  A  and  G^  =  0.5.  Finally  in  the  third  evaluation  (the 
sensitivity  run  for  kind  50)  we  use  G  -  =  0.75  and  G^^  =  0.5  -  A  . 
Anticipating  the  actual  EE  execution  in  which  PMIN=l.E-8,  we  set  A=  PMINxlO 
=  l.E-7.  The  results  for  the  three  runs  are  given  below. 

EVENT  PROBABILITY  CALCULATED  IN  EACH  OF  THREE  RUNS 
EVENT  REFERENCE  KIND  10  SENS.  KIND  50  SENS. 


300 

300^ 

0.075 

0.074999990 

0.075 

0.2625 

0.262499965 

0.2624999475 

3004 

0.1575 

0.157499979 

0.1575 

300^ 

0.505 

0.505000066 

0.5050000525 

10G 
10  U50 

G, 


-  0.7  G. „G 


108 


From  these  results  the  sensitivities  themselves  are  readily  found.  For 
example,  the  sensitivity  of  the  event  300  with  respect  to  kind  10  is  given 

by, 

0.075  -  0.0749999990  =  0.00000001 

A  0.0000001  u,i 

The  entire  set  of  sensitivities  are  shown  below. 


KIND 

300 

300 

300 

300 

0 

2 

4 

7 

10 

0.1 

0.35 

0.21 

-0.66 

50 

0.0 

0.525 

0.0 

-0.525 

In  this 

example 

,  because 

we  have 

the 

formulas  for  the  event 

probabilities , 

the 

sensitivities  could 

be 

directly  calculated  by 

differentiation 

We 

note  that 

identical 

results  would  be  obtained 

because  all  of  the  functions  are  linear  with  respect  to  each  variable. 

As  mentioned  earlier  our  interest  is  in  the  event  that  signal  300  takes 
on  a  value  of  either  2  or  4.  Denote  this  "selected  event"  by  E.  Then, 

E  =  3002  (+)  3004 

Where  0  is  the  logical  (boolean)  sum  ("OR"). 

Because  the  basic  events  300^  and  300^  are  mutually  exclusive,  the 
probability  of  E  is  given  by, 

P(E)  =  P(300  0  300  ) 

=  P(3002)  +  P(3004) 

Consequently  we  obtain  an  estimate  of  the  mean  of  P(E)  by  summing  the 
estimates  of  the  means  of  P(300^)  and  P(300^)  which  are  obtained  from  the 
reference  run.  Hence, 

m  =  0.1575  +  0.2625  =  0.42 


The  variance  of  P(E)  is  approximated  by 


v  =1 


Q>P(E) 


do 


10 


v10  + 


dP(E) 


dG 


50 


50 


where  is  the  variance  of  (i=10,50).  Now, 


dP(E) 

0G(1O) 


jdP(3002)  +  P(3004)[ 


d  g 


10 


0P(3OO„)  0P (300  ) 
2  +  4 


OG 


10 


dG 


10 
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But  these  terms  are  simply  the  sensitivities  of  the  events  3002  and  300^  with 
respect  to  kind  10.  A  similar  argument  can  be  applied  to 
P (E)  /  G  n,  and  we  finally  get  (recall  that  v^  =  0.0375  and 

v5Q  =  0.0001), 

v  =  (0.35  +  0.21)2  x  0#0375  +  (0.0515  +  0.0)2  x  0.0001 
=  0.01176  +  0.00002756625 
=  0.0117875625. 

Finally,  to  find  a  confidence  interval  for  the  mean  of  P(E),  we  use  m 
and  v  to  calculate  the  Easterling  pseudo  values. 


0.42(1-0.42) 
0.01 1788 


20.67  =  21 


x  =  0.42  x  21  =  8.82  =  9 

From  these  values  Burstein!s  computer  algorithm  gives  a  95%  lower  confidence 
bound  of  0.243  and  a  95%  confidence  interval  of  (0.216,  0.679). 


EE  Output 

This  sample  problem  was  executed  using  the  programs  G01,  EEl ,  EE2,  and 
EE3.  The  output  printouts  from  these  programs  are  shown  in  Figures  81,  82, 
83,  and  84.  The  G01  printout  is  recorded  in  Figure  81.  It  should  be 
self-explanatory  at  this  point. 

The  EEl  printout  (comparable  to  G02  data)  is  documented  in  Figure  82. 
The  data  for  the  three  kinds,  10,  30,  and  50,  are  listed.  Kinds  10  and  50  are 
variable  and  the  entries  G  and  B  communicate  this  fact  to  the  computer. 
The  kind  30  data  is  considered  to  be  exact  -  i.e.,  there  is  no  uncertainty. 
It  is  entered  exactly  as  in  G02. 

For  kinds  which  are  considered  variable  there  are  two  ways  to  enter  the 
data  —  either  as  the  values  for  the  mean  and  standard  deviation  or  as  the  two 
parameters  (  a  and  P  )  of  a  beta  distribution.  In  both  cases  the  data  is 
entered  after  the  normal  G02  kind  data  (with  G  and  B)  replacing  certain 
probabilities  considered  variable),  but  before  the  data  terminator  ($  or  /) . 

In  Figure  82  the  data  for  kind  10  was  entered  in  the  form  of  the  two 
parameters  of  a  beta  distribution.  In  this  case  &  =3  and  P  =£. 
Consequently,  from  the  expressions  for  the  mean  (  v  )  and  variance  (  a  ) 
of  a  beta  distribution. 


a+P  (ot+0)2(a+0+l) 

the  mean  is  0.75  and  the  variance  0.0375. 

For  kind  50  the  data  is  entered  explicitly  as  the  mean  and  standard 
deviation,  0.5  and  0.01  respectively. 
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G01  DATA  FOR  EE  EXAMPLE 

I N  F I  N  -•  7?  S  E  Q  ~  0  >  ERRORS”  25 

B I  AS  =  750  f  OPS«lf  S I GN AL~  1 

OPERATOR  DATA 

OP  DATA 


1  5  50  .100  $  COMP  1 

2  3  30  100  200  $  COMP  2 

3  1  10  200  300  $  COMP  3 

///A  0  300  $  FINAL  SIGNAL 

SIGNAL  DATA 

SOURCE  OPER  * 

SIGNAL  NUM  TYPE  KIND  USING  OPERATORS  (-  IF  DELETED  AT) 


100  15  50  -2 
200  2  3  30  -3 
300  31  10 

NUMBER  OF  OPERATORS  »  3 
NUMBER  OF  SIGNALS  =  3 
MAX  NUMBER  ACTIVE  -  1 
INFINITY  (NEVER)  =  7 


FINAL  SIGNALS  “  300 


FIGURE  81  G01  DATA  FOR  EE  EXAMPLE 


ill 


EE  1  DATA  FOR  EE  EXAMPLE 


MODEL?  GO  1  DATA  FOR  EE  EXAMPLE 
RECORD  KIND  DATA 

1  10  1  G  B  3  l  $  COMP  3 

GOOD "*75000000  *  BAD= . 25000000 

2  30  3  0*7  0.2  0.1  $  COMP  2 

3  50  5  3  2  G  A  0*3  7  B  0*5  0.01  $  COMP  1 

GOOD". 50000000  >  BAD  •“  .20000000 


USE  SUMMARY  TABLE.  ENTRY -KIND/TYPE ( FREQUENCY ) 


10/  1< 


l  ) 


30/  3  ( 


1  ) 


1 ) 


KIND  SUMMARY 

OAR I  ABLE  NUMBER  INPUT  « 
OARIABLE  NUMBER  USED  - 
NONVARIABLE  NUMBER  INPUT 
NONVARIABLE  NUMBER  USED 


3  OP/KIND  RECORDS  WRITTEN  ON  1  FILE  RECORDS. 


FIGURE  82  EE1  OUTPUT  DATA  FOR  EE  EXAMPLE 
VARIABLE  KIND  DATA 
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EE2  DATA  FOR  EE  EXAMPLE 


MODEL:  601  DATA  FOR  EE  EXAMPLE 
KINDS:  EEl  DATA  FOR  EE  EXAMPLE 

MAXIMUM  SIGNAL  VALUE  (INFINITY)  IS  7 
MAXIMUM  DISTRIBUTION  SIZE  IS  3000 
F'MIN-1  *0000E-08>  INTER  =  0 

NOV AR=0  f  D  F  A  C  T  =  10. Or  K0RD  =  1 


FINAL  EVENT  TABLE  (INFINITY  “  7) 

SIGNALS  AND  THEIR  VALUES 
EV  PROBABILITY  300 


1  7 . 50000E-02  0 

2  1.57500E-01  4 

3  2 ♦ 62500E-01  2 

4  5 . 05000E-01  7 


TOTAL  PROBABILITY  =  1.0000000000 
TOTAL  ERROR  =  0.0000000000 
DELTA  =  1.0000E-07 


VARIABLE  KIND  SENSITIVITIES  FOR  EVENTS  IN  ABOVE  TABLE 
( CHANGE- I N-E VENT -PROB/ CHANGE- I N- THE- K I ND-6- PROB ) 

EVENT  1  EVENT  2  EVENT  3  EVENT  4 

10(  1 , 000E-01 )  10(  2, 100E-01 )  50<  5.250E--01)  50 ( -5 ♦ 250E-0 1 ) 
50 (  0 ♦ OOOE+OO )  50 (  O.OOOE+OO)  10(  3.500E-01)  1 0 ( -6 . 600E-0 1 ) 


FIGURE  83  EE2  OUTPUT  DATA  FOR  EE  EXAMPLE 
PARTIAL  DERIVATIVES  FOR  SYSTEM  EVENTS 


113 


EE 3  DATA  FOR  EE  EXAMPLE 


0,8  0,9  0,95  0,99  $ 

RUN  NUMBER  1  DEFINITION  DATA 

0.800  0,900  0,950  0,990 

ALL  VARIABLE  KINDS  ARE  INCLUDED  IN  THE  ANALYSIS 

SELECTED  EVENT 

30  0  2  f 
300  4  $ 

EOR 

1.  300 (  2) 

2,  300 (  4) 

EVENT  CONTRIB  TO 

KIND  NAME  TYPE  USES  G  PROB.  G  VARIANCE  SENSITIVITY  EVENT  VAR. 


10  COMP  311  0.75000000  3.7500E-02  5.6000E-01  1.1760E-02 

50  COMP  1  5  1  0.50000000  1.  .0000E  -04  5.2500E-01  2.7563E-05 

EVENT  PROBABILITY  =  4 , 200000000E-0 1 
VARIANCE  ESTIMATE  =  1 . 178756250E-02 

EASTERLING  INTERVALS 


PSEUDO  SAMPLE  SIZE  *  21 

NUMBER  OF  SUCCESSES  «  9 

CONFIDENCE  LOWER  BOUND  TWO-SIDED  INTERVAL. 


0.8000  0.31802642 
0.9000  0.27552971 
0.9500  0,24268106 
0.9900  0,13702532 


0.27552971?  0,60029495 
0.24268106?  0.64246452 
0.21594365?  0.67881441 
0,1687151.9?  0.74872196 


FIGURE  84 

EE2  OUTPUT  DATA  FOR  EE  EXAMPLE  CONFIDENCE  BOUNDS 
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The  EE2  output  data  is  recorded  in  Figure  83.  It  first  records  the 
possible  system  events  —  just  like  a  typical  G03  run  —  then  records  the 
partial  derivatives  of  each  final  output  event  with  regard  to  each  variable 
kind  (10  and  50  in  this  model).  Note  that  the  events  are  numbered  in  the 
final  event  table,  then  referenced  by  number  in  the  sensitivity  table.  The 
partial  derivative  of  event  300^  with  regard  to  kind  50  is  0.525,  etc. 

The  results  from  program  EE3,  Figure  84,  contains  the  final  output  from 
an  Effect  Evaluation  execution.  The  user  has  the  capability  to  select  various 
confidence  levels  and  to  select  the  system  event  whose  probability  of 
occurrence  is  to  be  bounded. 

In  Figure  84,  one-  and  two-sided  bounds  for  the  compound  event  300^  or 
300^  at  confidence  levels  of  0.8,  0.9,  0.95,  and  0.99,  are  requested.  The 
mean,  variance,  partial  derivative,  and  contribution  to  the  variance  for  both 
kind  10  and  kind  50  are  recorded  in  table  form.  The  mean  probability  of 
occurrence  of  the  event  300^  or  300^  is  0.42  and  the  variance  estimate  is 
0.0118.  From  this  data  the  pseudo  sample  size  and  number  of  successes  of  21 
and  9  are  calculated.  These  values  are  then  used  with  binomial  theory  to 
calculate  the  confidence  bounds  at  the  specified  levels. 

For  example  a  95%  one-sided  lower  bound  on  the  event  mean,  estimated  at 
0.42,  is  0.243.  The  95%  two-sided  confidence  interval  is  0.216  to  0.679  as 
the  table  shows.  Note  that  as  the  confidence  increases  the  intervals  increase 
in  length  and  the  lower  bound  decreases.  One-  and  two-sided  confidence  bounds 
for  each  selected  confidence  level  is  provided  in  the  final  table. 

We  have  explained  and  demonstrated  by  means  of  an  example  the  theory  and 
application  of  the  Effect  Evaluation  codes  to  treat  data  uncertainties  and 
place  bounds  upon  the  probabilities  of  occurrence  of  system  events.  The 
method  is  easy  to  use,  extremely  flexible,  and  is  applicable  to  any  system 
regardless  of  its  complexity.  Further  details  about  the  EE  concept  and 
programs  are  available  in  the  KSC  GO  Fundamentals  and  GO  Reference  Manuals. 
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CHAPTER  7 

CONCLUSIONS  AND  RECOMMENDATIONS 


Conclusions 

GO  is  a  computerized  methodology  for  performing  RAM  assessments*  It  has 
widespread  application  for  performing  safety,  reliability,  availability, 
maintainability,  and  risk  assessments.  It  is  available  to  all  users. 

The  GO  methodology  provides  a  disciplined  approach  to  perform 
comprehensive  system  assessments.  The  procedure  has  been  qualified,  validated 
and  accepted  as  a  powerful  technique  which  provides  correct  results.  The  GO 
software  incorporates  all  the  necessary  classical  algorithms  to  accurately  and 
comprehensively  calculate  the  probabilities  of  occurrence  of  system  events  as 
a  function  of  the  probabilities  and  sequence  of  occurrence  of  component 
events . 


Use  of  the  GO  methodology  facilitates  computerized  reporting  and 
eliminates  much  time-consuming,  tedious,  error-prone  hand  processing  required 
by  other  assessment  methods.  GO  models  are  compact  and  easy  to  follow  because 
they  closely  track  original  schematics  or  flow  diagrams.  The  models  are 
easily  developed  by  engineers  without  extensive  specialization  and  the 
computer  software  is  easy  to  use  with  minimal  training.  Consequently,  the  GO 
methodology  eliminates  constraints  with  which  other  methods  are  encumbered. 

The  efficiency  of  the  GO  procedure  results  from  the  use  of  standardized 
logical  operators  (types) ,  supertypes  to  model  replicated  equipment 
configurations,  and  the  optimized  software.  This  efficiency,  both  in  analyst 
time  for  model  development  and  in  computer  manipulation  time,  permits 
extensive  and  exhaustive  system  assessments  with  reduced  costs  and  scientific 
labor. 

Use  of  the  GO  methodology  does  not  require  additional  sampling  or  testing 
programs.  To  employ  it,  no  new  data  requirements  are  imposed,  but  existing 
data  is  used  consistently  and  effectively  to  comprehensively  assess  system 
performance . 

The  GO  code  is  generally  applicable.  GO  models  can  be  developed  for 
almost  any  system. 

The  GO  procedure  provides  for  automatic  fault  identification  and 
treatment  of  data  uncertainties  without  additional  modeling  tasks. 
Sensitivities  and  confidence  bounds  on  the  probabilities  of  occurrence  of 
system  events  can  be  generated  automatically. 

Recommendations 

The  GO  software  is  currently  available  at  the  ARRADCOM,  Dover,  New 
Jersey,  installation.  It  is  recommended  that  other  commands  performing  RAM 
assessments  obtain  the  GO  software  and  establish  a  training  program  to  effect 
its  immediate  use  and  application. 
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